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 have noticed that I cannot follow a reference to class, method, etc that is defined in a source that is associated with a jar file defined as a library. I have restarted NetBeans in case some type of initialization must be done, but that didn't help. I should be able to navigate to source associated with third party jars if they are associated in the library definition right? Also, the sources for the third party jars do not show up by default in the available debugger sources. I had to add the same source definition again. The debugger did find the source after adding it manually, but I got an exception eventually, which I reported BTW.
Here is the stack trace when I attempted to follow the source in the debugger in case it is related: http://statistics.netbeans.org/exceptions/detail.do?id=10535
Could you please tell us what library and sources you are using? Also are you sure this isn't some sort of a configuration problem? Maybe, could you also possibly take a screenshot of the project classpath and the library customizers and attach them here. Thanks a lot
It is jdom.jar built with sources from cvs. It is possible that it is a configuration problem, but I seem to have this problem a lot. (It would be great if it is!) I'll see if I can find the classpath and library definitions for you. (What if I just send you my .netbeans/dev directory?)
The content of the folder .netbeans/dev/config/org-netbeans-api-project-libraries/ should be hopefully enough, it contains the libraries definitions. Thanks
I tried the following and the navigation worked fine, but I got an exception every time I opened a JDOM source file (or clicked its editor tab). I'm going to attach the log file, but first the steps: - download JDOM 1.0 from http://www.jdom.org/dist/binary/ - Tools -> Libraries -> New Library: name = JDOM, type = Class Libraries, added jaxen-*.jar, saxpath.jar, xalan.jar, xerces.jar from <jdom>/lib and <jdom>/build/jdom.jar - add <jdom>/src/java as a source root (Sources) and <jdom>/build/apidocs (Javadoc) - create new Java Application project and add JDOM library into it - in Main class or any other class in the project write eg. Document jdomDoc = null; jdomDoc.getContent(); - try ctrl-LMB click to navigate to the source file of Document class or its getContent method It seemed to work fine on my dev build with JDK5, except for the exception that poped out every time I opened a source file from the library.
Created attachment 52516 [details] The log file with the exception
The behavior is the same with JDK6.
For the exception see issue #121129.
I've fixed the NPE. Checking in org/netbeans/modules/java/source/classpath/GlobalSourcePath.java; /cvs/java/source/src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java,v <-- GlobalSourcePath.java new revision: 1.19; previous revision: 1.18 done Checking in org/netbeans/modules/java/source/usages/RepositoryUpdater.java; /cvs/java/source/src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java,v <-- RepositoryUpdater.java new revision: 1.106; previous revision: 1.105 done From your comment: >I tried the following and the navigation worked fine, but I got an exception every time I opened a JDOM source file (or >clicked its editor tab). I'm going to attach the log file, but first the steps: >- download JDOM 1.0 from http://www.jdom.org/dist/binary/ >- Tools -> Libraries -> New Library: name = JDOM, type = Class Libraries, added jaxen-*.jar, saxpath.jar, xalan.jar, >xerces.jar from <jdom>/lib and <jdom>/build/jdom.jar >- add <jdom>/src/java as a source root (Sources) and <jdom>/build/apidocs (Javadoc) >- create new Java Application project and add JDOM library into it >- in Main class or any other class in the project write eg. Document jdomDoc = null; jdomDoc.getContent(); >- try ctrl-LMB click to navigate to the source file of Document class or its getContent method >It seemed to work fine on my dev build with JDK5, except for the exception that poped out every time I opened a source >file from the library. it seems that the NPE was the only resting problem, right? Can you verify it? It will be hopefully in today's night build. Again thanks for your help.
I don't get an exception, but the editor will still not navigate to the 3rd party jdom source for the 11/06 build. In case it matters, I'm using the full distribution of NetBeans with jVi bindings: http://downloads.sourceforge.net/jvi/nbvi-POST-NB-BETA2-1.1.2.x2.zip I've disabled the bindings, but it didn't have any impact on the problem.
Reporter, could you please double-check that you have properly attached sources to the library (in this case you need (I think) "<jdom>/src/java" as source root, not eg. "<jdom>/src"). Thanks.
I will create a modified version of java module (added logging info to code finding the sources) and attach it to this issue. I've created simple j2se application with the library for jdom downloaded from http://www.jdom.org/dist/binary/ and it works fine in my setup.
I did find one way to force the editor to follow the JDOM source. For some odd reason, if I remove the jdom.jar from the library and add a copy of it from another directory. The editor will follow the source. Now, if I remove the new version from the library and then replace it with the path to the original jdom.jar, the editor still follows the source. When I change the library, the IDE does some recompiling of other sources and does some updating so perhaps there is a reference that needed an update. The previous scenario also held true if I created an entirely new $HOME/dev directory by moving my old one to a backup and the copying my original library definitions to the new dev directory.
I don't know if this matters, but the source code for the project that refers to jdom.jar is used as a source reference in another library. I've noticed that if I change the JDOM library that the a message appears in the status bar that the source from my project is being "compiled" (which I think means reindexed or something since it is already compiled.)
If I understand it correctly, you have: Project -------sources which depends on JDOM library (defined in Library manager) and there is also library in Library manager defined for Project (classpath=Project/dist/*.jar,sources=Project/sources). Right?
Yes. That is the case. I'll try removing the reference to source to see if that helps.
I've just found another case where the IDE is not allowing navigation to the source. I just recently tried out the Swing Application Framework integration in NetBeans (works great BTW!) and was trying to navigate to the source for Task org.jdesktop.application.Task. I downloaded and added path to the unzipped source for the Framework, navigated to Task and then tried to navigate to org.jdesktop.swingworker.SwingWorker. I downloaded and added the path to the unzipped source (src/java) for the SwingWorker to the "Swing Application Framework" library but could not navigate to the source. I tried restarting NetBeans, but that didn't work. I also tried removing the swing-worker.jar file from the library and re-adding it like I had done before, but that didn't work either.
The "Swing Application Framework" is added as a Library or project? The best will be if you can attach the test project, thanks.
I've tried the sent projects, thanks for them, the navigation to Action (Ctrl+Click) worked fine but the navigation from action to SwingWorker didn't work. Was it this case? If even the navigation to Action doesn't work can you run the IDE with: -J-Dorg.netbeans.api.java.queries.level=300 option? It will generate the logging info how the binaries are translated into sources. Please attach or send me the messages.log. Thanks. If the problem is that you are not able to navigate from Action to SwingWorker as I described above, this problem is caused by the project setup and I doubt we can do anything with it. The problem is: You downloaded the swing app framework sources and attached them to the Swing App Framework library (the jar files of these libraries are somewhere in NB folder). But the sources are complete project which provides it's own copy of SwingWorker.jar. So when you navigate from your app through the library to Action class you get into project for swing app framework and when you navigate to SwingWorker you navigate from the swing app framework which doesn't depend on the swing application framework library but on swingworker.jar located in the swingappframwrok/lib but the library doesn't know anything about this jar file, so it cannot translate it into sources. There are several ways how to solve this: 1) Change the swing app framework project to use the swing app framework library rather than lib/swingworker.jar 2) Change the swing app framework library to point to the swingworker.jar in the swing framework app project. 3) Delete the nbproject folder from swing app framework project, so it will become just a source folder not a project
I was able to navigate to the sources for Action, but not for SwingWorker. Just to be clear about my setup, I unzipped the sources for SwingWorker into another directory outside the application project and attached the source for it to the Swing Application Library using the path myswingworkerpath/src/java. I didn't (at least intentionally) use the swingworker.jar file in the source distribution. I'll try deleting the swingworker.jar from the source distribution to see if that works. (NetBeans must have done some magic behind the scenes to find this jar file.) As a side note, it looks like the swingworker.jar bundled with the Swing Application Framework didn't have the debugging symbols turned on so I can't step through the code. (Oddly enough, the source for Swing Worker did show up when I stepped through the code with the debugger even though I could not step through it.)
Created attachment 52979 [details] ide screen shot showing project definition and source
Created attachment 52980 [details] screen shot showing libraries used in project
Created attachment 52981 [details] shot showing wrong error badges related to IDE thinking that Swingworker isn't defined
Created attachment 52982 [details] swing worker source showing up during debugging
Created attachment 52983 [details] shot showing sources associated with used library
I removed swingworker.jar from the downloaded AppFramework project and even moved the src directory out of the project completely so that NetBeans wouldn't think that the src for the jsr296 framework was associated with another NetBeans project. So the only jar files referenced now are the ones bundled with the NetBeans IDE. (See http://www.netbeans.org/nonav/issues/showattachment.cgi/52980/cp.jpg and http://www.netbeans.org/nonav/issues/showattachment.cgi/52983/library-sources.jpg) But, I still cannot navigate to the SwingWorker source and the IDE editor seems to think that the SwingWorker class isn't defined. (See http://www.netbeans.org/nonav/issues/showattachment.cgi/52981/wrong-error-badges.jpg) The jar file is in the classpath though since the compiler can compile the project without errors. When I debug the application, the debugger can find the source for the SwingWorker, but since debug symbols aren't turned on it only displays the source. (See http://www.netbeans.org/nonav/issues/showattachment.cgi/52982/swing-worker-source.jpg)
I've been getting exceptions now as well that may be related: http://statistics.netbeans.org/exceptions/detail.do?id=3377 I went ahead and deleted the nbproject out of the C:\java\jsr296\appframework\AppFramework directory even though I had moved the src directory to: C:\java\jsr296\appframework\src. Now the SwingWorker source appeared when I navigated from Task to SwingWorker and the error badges disappeared. Why would an nbproject folder be relevant when the src wasn't in the same directory as AppFramework?
>(NetBeans must have done some magic behind the scenes to find this jar file.) It's not a magic, it's quite logical behavior. There was a library having 2 jar files af.jar (short name for app-framewrok) and sw.jar (short name for swingworker.jar) stored in NetBeans, say /netbeans/ folder). You downloaded sources and created let's say /libs/af and /libs/sw folders and add the folders /libs/af/src and /libs/sw/src/java to app framework library. So we have: /netbeans/**/af.jar /netbeans/**/sw.jar which maps to following sources: /libs/af/src/ /libs/sw/src/java but the /libs/af/src/ is a project which provides it's own classpath which is different from the classpath of your project. The /libs/af project has /libs/af/libs/sw.jar on classpath which has nothing in common with the /netbeans/**/sw.jar for which you defined the source root => it cannot find the sources for classes in /libs/af/libs/sw.jar, it doesn't matter if there is debug info or not, there is no source root to which it will be related.
>I've been getting exceptions now as well that may be related: >http://statistics.netbeans.org/exceptions/detail.do?id=3377 It's not related to this problem, it's just diagnostic exception which will be turned off in release saying that the class files differs from java source file. >I went ahead and deleted the nbproject out of the C:\java\jsr296\appframework\AppFramework directory even though I had >moved the src directory to: C:\java\jsr296\appframework\src. Now the SwingWorker source appeared when I navigated from >Task to SwingWorker and the error badges disappeared. Why would an nbproject folder be relevant when the src wasn't in >the same directory as AppFramework? Sorry, I am not sure if I get the setup correctly before you delete the nbproject folder. Please correct me if I am wrong. The setup was: Library: ClassPath={**/netbeans/**/appframework-1.0.3.jar,**/netbeans/**/swing-worker-1.1.jar}, SourcePath={C:\java\jsr296\appframework\src, C:\java\swing-wroker-1.1\src\java} In the C:\java\jsr296\appframework\lib you deleted the swing-wroker-1.1.jar but you keep the nbproject, right? So it will behave in similar way as in previous case it will go from your project to Action in C:\java\jsr296\appframework\src (project) with it's own classpath pointing to non existing C:\java\jsr296\appframework\lib\swing-wroker-1.1.jar - this is the reason why the errors are shown. You cannot navigate to SwingWorker since the project declares that it should be somewhere in C:\java\jsr296\appframework\lib\swing-wroker-1.1.jar which doesn't exist. Your project can be build because it uses the prebuild jar from netbeans not the sources. If you instead of deleting the the C:\java\jsr296\appframework\lib\swing-worker-1.1.jar remove the reference to it in the project customizer of C:\java\jsr296\appframework\ project and add there the swing application framework library everything should be fine. I will change the appframework project to behave in this way and send it to you.
Why did the source not show up when I moved the src directory out of the NetBeans project for appframework into a sibling directory? (jsr296/appframework/src and jsr296/appframework/AppFramework rather than jsr296/appframework/AppFramework/src) I still needed to delete the nbproject out of jsr296/appframework/AppFramework to cure the problem. Could there be a caching problem or is the project still found somehow even though the src is in a sibling folder to the NetBeans project? (There shouldn't be any ties to the two directories once I moved the src directory should there?)
>Why did the source not show up when I moved the src directory out of the NetBeans project for appframework into a >sibling directory? (jsr296/appframework/src and jsr296/appframework/AppFramework rather than >jsr296/appframework/AppFramework/src) This should work fine, if you correct the library definition to point to jsr296/appframework/src rather than to jsr296/appframework/AppFramewrok/src, also you have not to correct the project source root reference to point to the new source root. By other words the jsr296/appframework/src must not be owned by the project. >I still needed to delete the nbproject out of jsr296/appframework/AppFramework to cure the problem. Could there be a >caching problem or is the project still found somehow even though the src is in a sibling folder to the NetBeans >project? (There shouldn't be any ties to the two directories once I moved the src directory should there?) There is no persistent cache for such a information. Have you tried the modified Application Framework I've sent to you yesterday? It should work fine.
>This should work fine, if you correct the library definition to point to jsr296/appframework/src rather than to >jsr296/appframework/AppFramewrok/src, also you have not to correct the project source root reference to point to >the new source root. By other words the jsr296/appframework/src must not be owned by the project I think I did change the library definition to point to the new source, but I'll repeat the test to see if it works without removing the nbproject directory. BTW, why does the editor try to automatically include .jar files from sources associated with the library if I didn't explicitly specify the jar file in the library definition? I think that has been the most confusing part. Why did the debugger find the source when the editor couldn't? (They must be using different algorithms.) Is there a way to include a jar file with source in it that doesn't have the root of the package at the root of the jar? (i.e. com/domain/... rather than the typical project/src/com/domain/...)
>BTW, why does the editor try to automatically include .jar files from sources associated with the library if I didn't >explicitly specify the jar file in the library definition? I think that has been the most confusing part. Editor desn't include anything to classpath, it uses classpath provided by project system. The thing here is complicated by the fact that you attached sources of the project to library and the project is configured in such a way that it doesn't use the NetBean's swing app framework library. The following happened: 1) You are in your project editing the Main.java, project system provides classpath containing the swing app framework library {**/netbeans/**/appframework-1.0.3.jar,**/netbeans/**/swing-worker-1.1.jar} 2) Now you are navigate to Action, the editor uses the classpath and translates the jar files using the information you have entered into the LibraryManager to {C:\java\jsr296\appframework\src, C:\java\swing-wroker-1.1\src\java} and finds the Action.java. 3) Editor opens the Action.java, but it is in its own project with its own setup. Now comes the tricky part, editor asks about the classpath for Action.java and the appframework project aswers {C:\java\jsr296\appframework\lib\swing-wroker-1.1.jar} which is different swing-wroker-1.1.jar for which noone set the sources, so the editor is not able to navigate to SwingWorker.java >Why did the debugger find the source when the editor couldn't? (They must be using different algorithms.) Yes, it doesn't use project classpath but it uses all source roots of all opened projects + sources of platform + sources of libraries and take the first one. You can customize (enable|disable) it in Sources view of debugger. This is needed when you do an attach, the debugger doesn't know the classpath. So debugger opens firstly found file of given name. This cannot be used by editor since this is rather heuristic, there are cases when you need to disable some source roots in the source view to get the debugger to work fine, but debugger has no another chance at least in case of attach. >Is there a way to include a jar file with source in it that doesn't have the root of the package at the root of the jar? >(i.e. com/domain/... rather than the typical project/src/com/domain/...) I am not sure if I got this question. You need to attach sources contained in some jar(zip) for which the file root is not source root, right? There is no UI for it, but you can do following. Add the jar file like the root was the source root and then edit the library definition and change the root by hand. You need to do something like this, in this case the source root is src folder in src.zip: <volume> <type>src</type> <resource>jar:file:/usr/lib/mylib/src.jar!/</resource> </volume> to: <volume> <type>src</type> <resource>jar:file:/usr/lib/mylib/src.jar!/src/</resource> </volume> It's important that the URL ends with '/' in this case src/.
>I am not sure if I got this question. You need to attach sources contained in some jar(zip) for which the file root is >not source root, right? There is no UI for it, but you can do following. Add the jar file like the root was the source >root and then edit the library definition and change the root by hand. >You need to do something like this, in this case the source root is src folder in src.zip: ><volume> > <type>src</type> > <resource>jar:file:/usr/lib/mylib/src.jar!/</resource> ></volume> > >to: > <<volume> > <type>src</type> > <resource>jar:file:/usr/lib/mylib/src.jar!/src/</resource> ></volume> That is exactly what I need. If it isn't there already, I'll submit an enhancement request to add this capability to the UI. Thanks for answering all my questions! I still think there needs to be more feedback to the user regarding why the source isn't appearing or what jar file is being used. I realize that this is probably a special case since most of the time the jar and the src are probably from the same nb project and you wouldn't have this ambiguity problem. It might be good to bundle the srcs for all libraries bundled with NetBeans to avoid forcing people to download them separately or have the source available as an optional plug-in. (I didn't see that, but I'll check again.) I'd also encourage the NB team to compile all the bundled libraries with debugging symbols turned on to make it easier to step through the code.
OK, I am closing this issue. I've filled the request for source root != package root: http://www.netbeans.org/issues/show_bug.cgi?id=122155 I've already talked with Tomas Pavek about bundling the sources with Swing Application Framework library.