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.
I'm working within a project that is part of an EAR where all the components are using Maven 2. I'm trying to use the Navigate -> Go to source function (ctrl+click) in NetBeans 7.1. The class I want to navigate to is located in another project that is also a part of the EAR, and that is currently open in NetBeans as well. I had expected to navigate to the actual local source file in the project, but instead I'm getting the grey background read only version that you get when browsing sources attached to a jar. If the project does not have attached sources in Maven I only get the decompiled version. Steps to reproduce: 1. Create two plain Java SE Maven projects in NetBeans, and add one as a dependency to the other. 2. Then create a class in the first project, and use it in the second. The dependency is correctly shown as a project, not a jar, but "Go to source" only shows the read only "//compiled code" version. This works as expected in NetBeans 7.0.1, so something must have changed in 7.1.
(In reply to comment #0) > Steps to reproduce: > > 1. Create two plain Java SE Maven projects in NetBeans, and add one as a > dependency to the other. > 2. Then create a class in the first project, and use it in the second. The > dependency is correctly shown as a project, not a jar, but "Go to source" only > shows the read only "//compiled code" version. Working for me in a dev build. Check with a fresh NB installation on a different machine, perhaps, to see if something in your environment is preventing this from working.
Confirming the faulty behaviour on 7.1.1, build 201203012225. Code changes in the dependency project only propagate after explicitly building the project.
Just tried this again on a fresh Windows 7 installation using NetBeans IDE 7.1.1 (Build 201203012225), and it still doesn't work. Even after building both projects I can't navigate to the correct source file, ref Iikku's comment. Product Version: NetBeans IDE 7.1.1 (Build 201203012225) Java: 1.7.0_03; Java HotSpot(TM) 64-Bit Server VM 22.1-b02 System: Windows 7 version 6.1 running on amd64; Cp1252; no_NO (nb)
Sorry, still working for me also in 7.1.1 according to steps given in comment #0. Use Project Metadata Inspector plugin to look for unusual or mistaken project configuration. When run on the second project, it should show something like: "Source Packages" (1SourceRoot): .../test208228b/src/main/java ... classpath/compile: jar:file:.../test208228a/1.0-SNAPSHOT/test208228a-1.0-SNAPSHOT.jar!/ sources (authoritative): .../test208228a/src/main/java
Created attachment 117298 [details] Inspector output
I've attached the entire output from the plugin. The relevant bit: Java source roots: "Source Packages" (1SourceRoot): C:\code\mavenproject1\src\main\java source level: 1.5 encoding: UTF-8 binaries: C:\code\mavenproject1\target\classes test roots: C:\code\mavenproject1\src\test\java classpath/source: C:\code\mavenproject1\src\main\java classpath/compile: C:\devtools\maven_repo\com\mycompany\mavenproject2\1.0-SNAPSHOT\mavenproject2-1.0-SNAPSHOT.jar classpath/execute: The "sources (authorative)" line is missing, which fits with the behaviour we're seeing.
Created attachment 117322 [details] sample projects using the attached projects app1 and app2 where app2 depends on app1 and uses a class from app1, I cannot reproduce your problem in latest dev builds nor in the latest 7.1 based instance.
please try with the attached projects. If it does work with them, please modify the samples to make them fail. Also please note every steps to reproduce. Try both with your current userdirectory and a new empty one (using --userdir <path> on cmd line. See http://wiki.netbeans.org/FaqAlternateUserdir for details. additionally please attach the config\Preferences\org\netbeans\modules\maven\etternalOwners.properties file from your user directory. That could be further lead towards what is resolving to what. Thanks.
The most likely explanation is that the IDE does not know about C:\devtools\maven_repo\ and believes ~/.m2/repository/ is where it should be looking. <localRepository> in ~/.m2/settings.xml is honored if set (same for $MAVEN_HOME/conf/settings.xml for the Maven installation configured in the IDE's Options panel). Try playing with your local repo configuration.
I've been able to narrow this down to something related to the settings.xml, but I can't figure out what. With an empty settings.xml it works as expected, but with a minimal settings.xml I get the problem again. externalOwners.properties looks like this: com.mycompany\:mavenproject1=file:/C:/code/mavenproject1/ com.mycompany\:mavenproject2=file:/C:/code/mavenproject2/ settings.xml with error: <settings> <localRepository>c:\\devtools\\maven_repo</localRepository> <servers> <server> <id>dev_repo</id> <username>username</username> <password>password</password> </server> </servers> <profiles> <profile> <id>nexus</id> <!--Enable snapshots for the built in central repo to direct --> <!--all requests to nexus via the mirror --> <repositories> <repository> <id>central</id> <url>http://central</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url>http://central</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>nexus</activeProfile> </activeProfiles> </settings>
I can reproduce this using an external maven, or overriding the localRepository config of netbeans' bundled maven. I settled to using the bundled maven with the default localRepository, which works correctly, instead of tuning the configuration files of my external maven installation. The exact same external maven installation works on 7.0.1, though.
That workaround isn't an option for me unfortunately, since the default location is located on a network share.
the fact that it only fails with custom local repository and that your definition starts with lowercase C, I think this is a duplicate of issue 206050 which is fixed in current development builds. closing as duplicate of 206050 please try with a dev build (or upcoming 7.2 beta) and reopen in case this issue is not fixed yet. *** This bug has been marked as a duplicate of bug 206050 ***
(In reply to comment #10) > <localRepository>c:\\devtools\\maven_repo</localRepository> AFAIK there is no reason to escape backslashes in XML; that may also be tickling the bug.
I can confirm that issue 206050 was what was happening. Lowercased the driver letter, and everything started working as expected. Thanks, everyone!
I'm having this problem randomly with a PHP projecte, on a Javascript file. Double click in a name function in Navigator window simply don't work; if I search for the function name via ctrl+f inside source code tab, it will find it. Maybe after that, and/or after waiting some time (but not any "refreshing project" while this), I can come to Navigator windows and double click will work. I'm on Windows 7 x64, Netbeans 8.0.2
Hello. I have noticed the same thing in NetBeans v8.0.2 @ Win7x64. "Go to Source" (or double click) works only for some elements like CSS=>Classes and CSS=>Rules ( only those included inside <head><style>.classes</style></head>), also all of the items in the HTML tree. For the rest elements from the Navigator tree nothing happens when triggered.
(In reply to KietnaQuTak from comment #17) > Hello. I have noticed the same thing in NetBeans v8.0.2 @ Win7x64. "Go to > Source" (or double click) works only for some elements like CSS=>Classes and > CSS=>Rules ( only those included inside > <head><style>.classes</style></head>), also all of the items in the HTML > tree. For the rest elements from the Navigator tree nothing happens when > triggered. this issue was a specific problem in maven and was fixed in scope of issue #206050 from you mentioned it seems you have a different problem with a different project type. please file an issue accordingly *** This bug has been marked as a duplicate of bug 206050 ***