Bug 52354

Summary: NB projects don't handle cp.extra jars correctly
Product: apisupport Reporter: Torbjorn Norbye <tor>
Component: ProjectAssignee: Jesse Glick <jglick>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P1 CC: markdey, nnguyen, pjiricka, richunger
Version: 4.x   
Target Milestone: 5.x   
Hardware: All   
OS: All   
Whiteboard:
Issue Type: DEFECT Exception Report:
Bug Depends on: 54161    
Bug Blocks:    
Attachments: Commit log (it's a doozy!)

Description Torbjorn Norbye 2004-12-13 23:51:17 UTC
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.
Comment 1 Mark Dey 2004-12-21 03:24:58 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.
Comment 2 Jesse Glick 2004-12-21 16:22:59 UTC
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).
Comment 3 Rich Unger 2004-12-21 19:14:00 UTC
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.
Comment 4 Jesse Glick 2004-12-22 16:49:12 UTC
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)?
Comment 5 Rich Unger 2004-12-22 19:39:08 UTC
> 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.
Comment 6 Jesse Glick 2004-12-22 20:31:34 UTC
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.
Comment 7 Rich Unger 2005-02-10 21:59:39 UTC
*** Issue 54850 has been marked as a duplicate of this issue. ***
Comment 8 Jesse Glick 2005-04-15 00:16:17 UTC
Working on it.
Comment 9 Jesse Glick 2005-04-16 20:33:08 UTC
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).
Comment 10 Jesse Glick 2005-04-16 20:33:58 UTC
Created attachment 21687 [details]
Commit log (it's a doozy!)
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