Bug 208228 - Using “Navigate -> Go to source” with local Maven projects does not work properly
Using “Navigate -> Go to source” with local Maven projects does not work prop...
Status: RESOLVED DUPLICATE of bug 206050
Product: projects
Classification: Unclassified
Component: Maven
7.1
PC Windows 7 x64
: P3 (vote)
: 7.2
Assigned To: Milos Kleint
issues@projects
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-10 08:29 UTC by dapendragon
Modified: 2012-05-23 12:52 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Inspector output (18.18 KB, text/plain)
2012-03-27 06:18 UTC, dapendragon
Details
sample projects (4.83 KB, application/octet-stream)
2012-03-27 12:35 UTC, Milos Kleint
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dapendragon 2012-02-10 08:29:39 UTC
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.
Comment 1 Jesse Glick 2012-02-14 17:27:48 UTC
(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.
Comment 2 iikku 2012-03-20 09:15:07 UTC
Confirming the faulty behaviour on 7.1.1, build 201203012225.

Code changes in the dependency project only propagate after explicitly building the project.
Comment 3 dapendragon 2012-03-20 09:26:31 UTC
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)
Comment 4 Jesse Glick 2012-03-26 22:52:31 UTC
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
Comment 5 dapendragon 2012-03-27 06:18:56 UTC
Created attachment 117298 [details]
Inspector output
Comment 6 dapendragon 2012-03-27 06:21:50 UTC
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.
Comment 7 Milos Kleint 2012-03-27 12:35:56 UTC
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.
Comment 8 Milos Kleint 2012-03-27 12:42:28 UTC
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.
Comment 9 Jesse Glick 2012-03-27 19:49:13 UTC
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.
Comment 10 dapendragon 2012-05-22 09:20:22 UTC
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>
Comment 11 iikku 2012-05-22 09:27:30 UTC
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.
Comment 12 dapendragon 2012-05-22 09:29:53 UTC
That workaround isn't an option for me unfortunately, since the default location is located on a network share.
Comment 13 Milos Kleint 2012-05-22 10:38:11 UTC
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 ***
Comment 14 Jesse Glick 2012-05-22 16:58:46 UTC
(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.
Comment 15 dapendragon 2012-05-23 12:52:38 UTC
I can confirm that issue 206050 was what was happening. Lowercased the driver letter, and everything started working as expected. Thanks, everyone!


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo