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.
Consider a "jar" library such as the xerces wrapper: it's a netbeans project, that also has a couple of bundled jar files. These are imported and made available to project clients at runtime via the Class-Path: entry in the manifest file of the library wrapper project. If I declare a dependency on the wrapper project, it will correctly add a runtime (manifest) dependency on the wrapper project, and it will make sure that when I compile my module it adds the jar file for the library wrapper project to my module. But it does NOT include the wrapped jars (in this case, xerces -2.6.2.jar and the dom-ranges.jar files) to the compile path! Thus, client projects need to not only declare a dependency on the wrapper project, they also need to add the xerces jars themselves to their own ${cp.extra} definition in project.properties. I think this should be automated. This shows up as a second problem as well: even if I add the extra jars to ${cp.extra} (so compilation works), if I open this project inside NetBeans, the external jars are somehow not added to the classpath that the editor knows about, and import statements relating to these classes show up as underlined errors in the editor.
Requesting a patch for 4.0 since it is important for our team to be able to use NetBeans to develop NB projectized modules. Currently, the inability to add external jars to the module's code completion classpath is a major impediment.
As mentioned separately, cp.extra does work for me (e.g. apisupport module), and is in fact unit tested, so you are doing something wrong - figure out what and file a separate bug if necessary. E.g. check the Classpaths section of your Java source file (NB dev builds only), or use -J-Dorg.netbeans.api.classpath.ClassPath=0 (NB dev builds only). This issue is about one thing only: if A depends on B and B includes some Class-Path JARs, A should see those in its code completion (at least if B includes those packages in its public packages list, though it may not be feasible to avoid showing them if it does not).
Looking forward, I think we're eventually going to want some kind of GUI for specifying dependencies in NbmProjects. If so, we're probably going to wish for a schema change. Something like a <jar-dependencies><jar path="lib/xerces.jar"/></jar-dependencies> as a sibling to <module-dependencies/>. This would pull "lib/xerces.jar" into the compile classpath, copy the jar to ${nb.modules.dir}/ext, add it to the set of module.files, and add it to the manifest's ClassPath.
The proposed <jar-dependencies> may be a good idea, though there are some fuzzy areas that need to be specified. What is the "path" here? Relative to project dir? What do you do if you need to unscramble something first? or what if you unpack the JAR directly from some ZIP file (though no one I think does this currently)? Do you need to set a different name for the JAR in modules/ext/? What about secondary source roots - are they handled at all? If there is already something in Class-Path should the new stuff be merged in? or should there be no Class-Path in the original manifest.mf (meaning that JavaHelp support has to add the appropriate entry too)?
> What is the "path" here? Relative to project dir? That was the idea. > What do you do if you need to unscramble something first? I think this is really an orthogonal issue. The current build file for the tomcat5 module (for example) doesn't unscramble the tomcat jar. It just overrides the init task to add a dependency on the build file in ../external. I don't see that this has to change. >or what if you unpack the JAR directly from some ZIP file > (though no one I think does this currently)? Same answer. >Do you need to set a different name for the JAR in modules/ext/? I'm not sure I understand what you mean here. Do you mean that you might want foo.jar to be called bar.jar when you copy it to ext/? This is probably an unusual case, and could be handled like the unscrambling case. Just have init copy the jar to the new name and depend on that. > What about secondary source roots - are they handled at all? I don't understand what you mean. What's the problem? > If there is already something in Class-Path should the new stuff > be merged in? or should there be no > Class-Path in the original manifest.mf (meaning that > JavaHelp support has to add the appropriate entry too)? Either would probably be fine. I was thinking the latter.
Re. having a different name in modules/ext/: not so unusual I think. Probably less so now that external/*.jar are supposed to include specific version info in the names, but still probably happens in some cases. Have to check. Re. unpacking directly from a ZIP - if this is needed (not sure), the problem is that you would have to introduce an extra copy operation. Re. secondary source roots - probably no problem, just this mechanism would not help with them. One thing that needs to be done carefully is to make sure that JARs in classpaths reported to the IDE are not normally recreated, since then the classpath scanning will pop up momentarily during a build, which is annoying. Originally I had wanted to have apisupport/project read extra JARs directly from Class-Path, but it does not work well since (1) you get a rescan if you rebuild the module, (2) you get background parser errors if the module is cleaned. You will still have the same problem with external/foo.jar during a real-clean build, since foo.jar will be deleted and then unscrambled, but that isn't as bad since it doesn't happen as frequently.
*** Issue 54850 has been marked as a duplicate of this issue. ***
Working on it.
You can now specify <class-path-extension>s in project.xml. This *will* affect your JAR's Class-Path, as well as the effective classpath of your module and any modules depending on you, both during the build and inside the IDE. It *does not* remove the need to specify these extensions in ${extra.module.files}, nor does it remove the need to copy them to the modules/ext/ directory (or wherever) during the build. There seemed to be too many variations on how the copying is actually handled in modules to try to automate this yet, including renames, special unscrambling steps, etc. (though it could be automated for most modules in the future). The project.xml syntax does permit you to specify the origin of the JAR separately, since this is needed to prevent excess classpath rescanning (see previous note).
Created attachment 21687 [details] Commit log (it's a doozy!)