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.
In a maven project, navigating through sources (e.g. Ctrl+click on a method) works fine until the project is built. After that, navigator opens source code from -source.jar. STR: 1) git clone git://github.com/jbossas/jboss-as.git 2) Open the project in NetBeans 3) Open the testsuite/domain module 4) Open the testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/AdminOnlyModeTestCase.java file 5) Line 123, Ctrl + click on the method domainMasterLifecycleUtil.executeAwaitConnectionClosed(op); This works fine. 6) cd jboss-as ./build.sh 7) Click the method again A source from built ...-source.jar will pop up (despite the correct one is already open) ~/.m2/repository/org/jboss/as/jboss-as-testsuite-shared/7.2.0.Alpha1-redhat-2/jboss-as-testsuite-shared-7.2.0.Alpha1-redhat-2-sources.jar:org/jboss/as/test/integration/domain/management/util/DomainLifecycleUtil.java
I will try with latest dev build.
after building, I don't get jboss-as-testsuite-shared-7.2.0.Alpha1-redhat-2-sources.jar in my local repository. At the same time, hyperlinking at the mentioned place always takes me to the right source file. Product Version: NetBeans IDE Dev (Build 201301180001) Updates: Updates available Java: 1.6.0_37; Java HotSpot(TM) 64-Bit Server VM 20.12-b01-434 Runtime: Java(TM) SE Runtime Environment 1.6.0_37-b06-434-11M3909 System: Mac OS X version 10.8.2 running on x86_64; MacRoman; en_US (nb) same results with latest custom built dev build. next time it would be nice to be warned that the standard heap size is not enough, I've got stuck in endless GC cycle fairly fast.
Seems to be hard to reproduce, but it really happens. Maybe attaching some log would help? Or part of NB user directory? I run now on nightly build from friday so let's see whether it still happens.
another thing that might help is installing the "Netbeans project metadata inspector" module and when the problem occurs, try executing the "inspect project metadata" action on owning project's popup menu. That should print out additional information about the current project classpath.
please note that as part of fix for issue 226679 i've changed the inter-project bindings for artifacts with classifier. previously such links were not established at all, now they are, but the binary is preferred in this case, not the source root. meaning the java compiler in the IDE will not scan/compile the source roots, but only the binary. So changes in sources will not be reflected in dependeding projects until the binary is recreated/updated.
appears to be related to "org.lee." groupId, with groupId="org.lee" everything works fine. The alternative with dot at the end appears not to create links between the 2 projects. -> P3, not a mainstream usecase, still maven compiles it fine.
sorry different issue.. (In reply to comment #6) > appears to be related to "org.lee." groupId, with groupId="org.lee" everything > works fine. The alternative with dot at the end appears not to create links > between the 2 projects. > > -> P3, not a mainstream usecase, still maven compiles it fine.
did it happen again? what was the value in Properties? (compilation classpath) can you attach the log file when the problem appears? a simplified setup is to open testsuite/shared + testsuite/domain projects only. The hyperlink to the dependency's should work then as well. I believe the randomly seen problems could be associated with low memory conditions where scanning doesn't properly finish or when the maven project doesn't get reloaded upon changes some pom files (like only parent poms change). Please note that while shared project contains <version>7.2.0.Alpha1-SNAPSHOT</version> version element, the domain pom doesn't contain it. Therefore it's possible that a change in inherited version can temporarily put the 2 poms out of sync. (we only reload project automatically when it's own pom changes. Changes in parent don't get propagated automatically due to likely performance hit when a parent pom is changed and all the child projects need to be reloaded.
issue 228853 could also be related. marking as incomplete, please reopen with additional details.