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.
100726-752957417950 (similar behavior observed also in maven-dev). Check out GFv3 trunk sources and build them so that snapshots are prepopulated in local repo. Now open ejb/ejb-container and look at the Libraries node. All deps are shown as binary JARs whereas I would expect to see source project nodes, since sources are available in the same module tree. Similarly, open BaseContainerBuilder.java and ctrl-click on the import for "DeploymentContext". Opens org/glassfish/api/deployment/DeploymentContext.java in ~/.m2/repository/org/glassfish/common/glassfish-api/3.1-SNAPSHOT/glassfish-api-3.1-SNAPSHOT-sources.jar. Now open the root POM project (w/o deps). All of the deps on other modules in the tree switch to the project icon, which is OK, and ctrl-click now takes me to the editable source file DeploymentContext.java. But now Find Usages on the declaration of DeploymentContext does not list BaseContainerBuilder, only classes in the same module. Console also shows: WARNING [org.netbeans.modules.java.source.parsing.JavacParser]: ClassPath identity changed for AbstractFileObject@1e5abbc[org/glassfish/api/deployment/DeploymentContext.java], class path owner: null original sourcePath: new sourcePath: null INFO [org.netbeans.modules.java.hints.WrongPackageSuggestion]: source cp is either null or does not contain the compiled source cp= In maven-dev, after restarting the IDE (with the same projects open), Find Usages does work. This indicates to me that the maven module is returning a SourceForBinaryQuery.Result (or ClassPath?) which is not correctly firing changes after the right source project is discovered. In trunk I see the same behavior, though the restart is extremely slow as "Collecting dependencies" takes several minutes.
There should be no need to prebuild everything, but as is documented on the GF site you do have to run mvn -Prelease-phase1 install to get things set up initially. They have the policy of using snapshot versions of a plugin inside the source tree.
Created attachment 106997 [details] Experimental patch Crude attempt to ameliorate the problem by automatically reloading several other broken projects when one broken project is fixed. Helps somewhat, though does not fully solve the issue; the IDE does not really understand which broken projects might be fixed by what actual change. Bug #189442 and bug #175472 are variants.
(In reply to comment #0) > All deps are shown as binary JARs whereas I would expect to see source project > nodes, since sources are available in the same module tree. This and most other issues solved with bug #200445. > the maven module is returning a > SourceForBinaryQuery.Result (or ClassPath?) which is not correctly firing > changes after the right source project is discovered. Probably same as bug #192647 or similar. *** This bug has been marked as a duplicate of bug 200445 ***
Still some problems in 7.1. With a repo devoid of GF artifacts, working on revision 52520, opened root POM and did priming build. Then opened appserver/transaction/* submodules. Some error badges remained - the editor claimed to not be able to find classes which clearly existed in dependencies, even as shown under Dependencies. Specifically, TransactionServerInterceptor.java claimed to not find JavaEETransactionManager; JavaEETransactionManager.java claimed to not find ComponentInvocation; opened nucleus/common/glassfish-api and ComponentInvocation.java claimed to not find Scoped. At that point I saw that glassfish-api's Dependencies listed hk2 but not hk2-api. I reloaded glassfish-api's POM and hk2-api along with much else appeared, and then its error badges went away. Then switching back to JavaEETransactionManager.java, its error badge disappeared, and TransactionServerInterceptor.java's badge disappeared too after some fiddling - but then came back later, inexplicably, after opening some other projects (appserver/jdbc/jdbc-ra/*) and priming them. A similar issue continues to happen on a clean repo with nbm-maven-plugin: even after priming, it shows some error badges related to maven-dependency-tree, which in turn has to be opened and reloaded. Possible fixes: 1. Figure out why glassfish-api's POM was not being reloaded automatically when it ought to have been fixed by priming builds. Perhaps because this project was not open? 2. Provide some intuitive way for the user to ask that all POMs in memory should be reloaded at once. (Ideally this would also force the Java scanner to reconsider its error badges, which are probably wrong by this point.)
this is related to issue #198880, not sure if a duplicate or not.
At least the symptoms are not a duplicate. In this case, the problem is that some POMs do not get reloaded automatically, but when they are, everything refreshes and is fine. In bug #198880, the POMs are reloaded but the problem remains because of missing artifacts.
if everything works for properly compiled/built source base that was built before opening the IDE, I would say we got the 90% of mainstream usage covered. The remaining 10% is the gray zone with can be influenced by so many moving parts that I don't consider it practical to attempt achieving perfection. A few known gray area fuzziness contributors: 1. unopened projects are the major one. Once a pom packaging project is hit, subproject provider will load child projects, which unlike the pom project are more frequently broken. These projects never get reloaded, influence other queries like SFBQ via MavenFileOwnerQuery. 2. in MFOQImpl persistence of local repo jar -> project base dir url helps at constructing inter-project dependencies on repeated IDE restarts, but is counter productive when multiple checkouts of the same sources are used. 3. for 7.3 we've solved the duality of project owned and flat repository SFBQ.Result, previously repository Results held by 3rd parties never learned that the source is now routed to a project. 4. an unwanted sideeffect of 2+3 is that there's currently no way of removing inter-project links appearing in the IDE. in older versions one could limit the linking by the projects one opened. closing the projects, eventually restarting resulted in the possibly faulty link to be abandoned. Nowadays the links are there forever, never disappearing, but more importantly, not manageable by the user. 5. Opening order of projects is in no way related to build order, resulting in some project interdependencies being resolved and some not at a given time, later possibly causing cascades of event fires. With the rise of native listeners we could try some more creative ways of reloading projects. eg. triggered by change in local repository artifact (caused by mvn install). That would be a more natural change triggering process compared to iterating the <module> tree of a parent pom. But in general I believe the case of "non compiled, missing artifacts in local repo, maybe broken" group of projects is too hard to support at 100%. At least given the current constraints we have in the project system.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss