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.
Summary: | NB projects don't handle cp.extra jars correctly | ||
---|---|---|---|
Product: | apisupport | Reporter: | Torbjorn Norbye <tor> |
Component: | Project | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | markdey, nnguyen, pjiricka, richunger |
Priority: | P1 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 54161 | ||
Bug Blocks: | |||
Attachments: | Commit log (it's a doozy!) |
Description
Torbjorn Norbye
2004-12-13 23:51:17 UTC
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!)
|