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.

Bug 70894 - Lib Wrapper Module project should be able to use AntArtifact's to rebuild JARs from subprojects
Summary: Lib Wrapper Module project should be able to use AntArtifact's to rebuild JAR...
Status: NEW
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker with 10 votes (vote)
Assignee: pgebauer
: 131049 144257 179142 182526 (view as bug list)
Depends on:
Reported: 2006-01-01 22:56 UTC by kitfox
Modified: 2015-09-09 11:22 UTC (History)
7 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description kitfox 2006-01-01 22:56:53 UTC
I have a free form project in NetBeans which produces a JAR file.  I've also
written a module that needs to use files in the JAR produced by the first
project.  I've included my JAR in my module suite by using the wizard to create
a Library Wrapper Module Project.  However, when I make changes to my freeform
project and recompile my JAR, my module is not updated.  Insetad, I have to
manually delete a copy of the JAR in the Suite and copy my updated JAR in to
replace it.

The Library Wrapper Module Project should keep track of the path of the original
JAR and update it when it's project is Clean/Builded.
Comment 1 Jesse Glick 2006-01-02 20:57:36 UTC
There are various build script modifications you can make to accomplish this
yourself, as explained in the FAQ:

Possible in principle to have the lib wrapper module project automatically
detect that a JAR with which it was configured was in fact a build artifact,
then deal with it specially: rather than copy it, refer to its original location
in <class-path-extension>, add an entry to ${extra.module.files}, and insert a
target override into build-impl.xml to cause building (or cleaning) the lib
wrapper project to build (or clean) the origin project too, as e.g.
j2seproject's do.

Not trivial and would I think require some format changes in project.xml. No
immediate plans to work on this; for now, users should update their build.xml
manually as described above.
Comment 2 misterm 2006-01-06 12:47:38 UTC
I do believe this is a very common situation for framework/library writers and 
should be implemented for the next NB release.
Comment 3 Jesse Glick 2006-01-06 21:54:32 UTC
Will consider scheduling it, no promises yet.
Comment 4 Jesse Glick 2006-12-06 20:18:58 UTC
Updated URL:
Comment 5 Jesse Glick 2007-07-19 18:04:53 UTC
In issue #110312 as a side note it is suggested to remove <extra-compilation-unit> from apisupport project.xml's and
replace with child j2seproject's, which would require this RFE to be implemented for comfort.
Comment 6 bobuse 2008-04-11 16:30:11 UTC
No news for this issue ?
I confirm that this situation could be frequent (it is in my case). Could we imagine an option in the library wrapper 
module creation wizard to pick up the java project to link to the created module ?
Comment 7 Jesse Glick 2008-04-11 16:54:03 UTC
It is not so trivial. Just changing the wizard is not enough. Requires matching changes in the build harness,
project.xml format, probably some query changes in apisupport.project.
Comment 8 Jesse Glick 2008-08-23 16:34:02 UTC
*** Issue 144257 has been marked as a duplicate of this issue. ***
Comment 9 _ moser 2008-08-23 22:54:06 UTC
As issue 144898 was marked as a duplicate of this issue, I just wanted underline that issue 144898 is requesting to
enable refactoring between Library Wrapper Modules and their source projects. IMHO, this is not what this issue
originally requested, as it is about to simplify hooking up the projects using the IDE to get code-completion,
goto-sorce, javadoc, etc.
Comment 10 Jesse Glick 2008-08-25 16:40:49 UTC
moser - correct correspondence between binaries and sources enables a host of features as a block, including refactoring.
Comment 11 _ moser 2008-08-25 17:08:04 UTC
Never meant to say issue 144898 but issue 144257 instead, sorry.
Comment 12 _ moser 2008-08-25 17:15:41 UTC
"correct correspondence between binaries and sources enables a host of features as a block, including refactoring."

1) Does this mean that Method 1 from is not a correct setup. If so, that
should be mentioned in the FAQ. 

2) Does this mean that using Method 2 from will give me refactoring as
described in Issue 144257 ? Except for refactoring Method 1 works fine for me and I also prefer push over pull in this
case. So only when I actually will get refactoring I would give Method 2 a try.


Comment 13 _ moser 2008-08-25 22:21:06 UTC
I just triple-checked my issue again using NetBeans IDE Dev (Build 200808241401) - and I'm stunned - it seems to work
even with method 1. Believe me, I already have had double-checked the issue to ensure the problem was reproducable
before I started all the complaining. Either there is something in the newer builds which made this work or there is is
bug which lets refactoring between library wrappers and their source projects sometimes work and sometimes not. However,
thanks for listening.
Comment 14 Jesse Glick 2008-08-25 22:32:19 UTC
I think method #2 would be more reliable than #1 because the JAR is then clearly "owned" by the j2seproject, not the
module project. I doubt there have been relevant changes in 6.5 development builds.
Comment 15 rmichalsky 2008-09-18 16:24:47 UTC
*** Issue 131049 has been marked as a duplicate of this issue. ***
Comment 16 Jesse Glick 2008-09-22 23:28:30 UTC
To implement, it would be necessary to have apisupport.project use ReferenceHelper to track child j2seproject's (or any
other AntArtifactProvider-containing projects). Then its build-impl.xml stylesheet would need to override some newly
introduced optional targets like 'deps-jar' and 'deps-clean' in harness/common.xml when there were some references.
Would need some GUI to add these dependencies too. Best to ask people about how j2seproject dependencies are
implemented. Not simple but doable.
Comment 17 rmichalsky 2008-10-15 10:23:57 UTC
If time permits.
Comment 18 puce 2008-12-11 15:38:56 UTC
Also the list of public packages should be updated if some packages were removed/ added.
Comment 19 Jesse Glick 2008-12-11 15:41:37 UTC
A lib wrapper module does not necessarily expose all packages from the lib as public.
Comment 20 puce 2008-12-11 15:52:03 UTC
Hmm, true, I just thought about the common case, which also is addressed by the "Library Wrapper Module" wizard: all
packages are added to the public packages list.

But it's true, that afterwards some packages might have been removed manually by the user from the list of the public
packages. So the library wrapper module would have to manage a list of explicitly exluded packages. Don't know if this
is a good idea or not, though.

And some new packages might not be public, too (but could default to be public as the wizard does).

At least the removed packages should be removed from the list.

Comment 21 Jesse Glick 2008-12-11 16:16:42 UTC
Changing how the list of public packages is represented on disk could be disruptive. Currently there is a fixed format
in nbproject/project.xml enumerating public packages. This is the same for library wrapper modules as for any other
modules; in fact there is no such thing as a "library wrapper module" beyond the template to initially create one.

One possible solution would be to use the <subpackages> element, which is permitted by the schema but not yet handled by
the GUI. The New Lib Wrapper Module wizard could use <subpackages> instead of enumerating existing packages in the lib.
The Properties dialog would then need to handle this element so you could use the GUI to refine the list if you wanted.
I'm not sure exactly what the GUI would look like, since mixing <package> and <subpackages> would be hard to represent
with the current simple list of checkboxes. Perhaps a radio button, with choices "Export All Packages" and "Pick
Packages to Export", with the list of checkboxes being enabled only if the latter is selected.

One snag is that for now <subpackages> requires at least one path component such as "org" or "com", so if you started
the library with org.something.** classes and later added com.something.** classes this trick would not work. (I expect
this is a rare situation.) Could probably relax schema to permit <subpackages/> to mean "all packages are public".
Comment 22 Jesse Glick 2010-02-03 16:45:50 UTC
*** Bug 179142 has been marked as a duplicate of this bug. ***
Comment 23 Jesse Glick 2010-02-03 21:30:24 UTC
*** Bug 179142 has been marked as a duplicate of this bug. ***
Comment 24 Jesse Glick 2010-03-22 21:40:36 UTC
*** Bug 182526 has been marked as a duplicate of this bug. ***
Comment 25 greggwon 2012-07-05 17:29:11 UTC
I'd like to suggest a different solution that just involves the option, in creating a wrapper, to designate the source jar file(s), and optionally, a project that builds that jar.  If that is the all that is specified, than it should also be optional to build the jar, if there is no project by that name/GUID.  I think it would be best for a project GUID to be the selection match for the building project.

Ultimately, I want to have an open source netbeans platform project, which uses about 10 different jar files from 4 different projects.  I don't want to burden users/developers of modules for this project with having to get every single project in order to build new modules.  So, I'd like for the wrapper module, to hold the jar and make it available for building the project and any additional modules the developer is working on.  But, only if they are actually adding something to one of the other modules, which has a wrapper, should they need to have those projects opened in the IDE.

Certainly, there is a lot of manual mechanisms to do exactly this today, but my target developer base won't really have the expertise to deal with those "details", and I don't want to have all of these barriers to getting developers to use the NBP app platform that I am trying to put together, just because it is "so large and complex".