This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Added ClassPath.getFlags() returning the ClassPath's flags. Currently just INCOMPLETE flag is defined. An INCOMPLETE ClassPath is not scanned unless it's resolved and the INCOMPLETE flag is removed.
Created attachment 148432 [details] Diff file
Y01 I can't find a single test. Y02 I would add <usecase> tag into arch.xml and describe what this is good for - I mean you asked some questions about proper behavior in an email - adding them and their answers into documentation would imho be ideal.
Y01: OK, I will add. Y02: Unfortunately I don't have the answers ;-)
Created attachment 148438 [details] Diff file Added Unit Tests
Opened questions: The ClassPath.Flags.ICOMPLETE flag is used to signal the language infrastructure that the classpath is in transient state (e.g. Maven project before build with no downloaded artefacts) and it should not be analysed. Also the directly dependent classpath should not be analysed. The goal is to solve the double scan when a Maven project is opened. The open causes first scan with lots of errors. The second scan comes after the build which downloaded the artefacts, and resolves errors from the first build. This proposed patch solves the problem. The first scan is not done and a special error is added into beginning of each java file "Missing mandatory ClassPath entries, Resolve Project Problems". The open question what to do with a transition from INCOMPLETE to COMPLETE state, e.g. users adds a new dependency to pom.xml. Currently such a transition disables scanning of already scanned root. Errors in the editor are kept and extended by "Missing mandatory ClassPath entries, Resolve Project Problems". As such a root is unregistered from parsing.api it's not scanned anymore which implies that new types, methods, etc. in such root are not available in code completion and navigation. This seems to me unacceptable.
Changing fast API review to regular API review due to opened questions which needs to be resolved.
When ClassPath changes from COMPLETE to INCOMPLETE, I would prefer to keep as much from previous information and use it up until when it becomes COMPLETE again - then let's update all the internal information: - if user adds new library dependency - if user removes JAR of already indexed library let's continue working with the information available before the user action. Once the JAR of new dependency or old dependency is downloaded (and ClassPath becomes COMPLETE again), re-scan the whole project.
I am going to integrate the patch.
Fixed jet-main 82910b5636e9