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 56684 - lib jar file refs in
Summary: lib jar file refs in
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: David Konecny
Depends on: 49638
Blocks: 56795 56796
  Show dependency tree
Reported: 2005-03-20 00:03 UTC by wqtnetbeans
Modified: 2008-04-09 00:51 UTC (History)
4 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description wqtnetbeans 2005-03-20 00:03:47 UTC
I am on the Mar-17 daily of 4.1. Created a web project with existing sources.
Found all the references used to lib jar files are stored in both and And the build-impl.xml file is using
the refs in I guess this will cause trouble if I want to run
the Ant script outside of the IDE.
Comment 1 Jesse Glick 2005-03-21 10:39:06 UTC
Wrong component (probably).
Comment 2 Pavel Buzek 2005-03-21 14:23:07 UTC
Can you describe what is the problem? Does it really cause any trouble? How can
I reproduce it?
Comment 3 wqtnetbeans 2005-03-21 17:00:18 UTC
The problem is that the Ant script does not work without the content under the
private/ folder.

To reproduce:

1. Create a "web app with existing sources". In there, specify some jar files as
the src compile lib that need to be copied in WEB-INF/lib. Notice that those jar
files are from a folder outside of the web context, but within the same CVS module.

2. Commit all the files in CVS, minus the private/ folder.

3. Check out the files from command line, and run the build.

Expected result: build runs OK.

Actual result: build fails citing "could not find file

I think the reason is that the build-impl.xml is taking the file refs in
"" rather than the ones in "". IMO those
refs should not be put into "" in the first place if we want
the script to run outside the IDE.
Comment 4 Pavel Buzek 2005-03-21 18:18:11 UTC
This is correct. When you c/o from cvs you have to update the

This is a result of removal of copyfiles custom task and suggested solution from
J2EE modules API review. The build-impl.xml needs to have properties for
individual files or directories because library or project can provide multiple
directories that copy task cannot handle.

I will try not to refer to in case you only have one file or
folder. This should solve the problem you have with files. 

For references to projects we now (in 4.1) only have one output file per project
so this should work too, but in general this is still a problem as a project can
have multiple outputs, even for one target (AntArtifact). I do not know how to
solve that.

For libraries the only alternative that I see is that the properties web project
has in private.propeties would be stored directly in file. I
think this would be possible, but need comment from Tomas.
(Tomas, the private props web project now stores are like:

Note that if you have a library in your project the IDE has to know the location
of netbeans userdir anyway to load the - this is stored in - so it would not work completely w/o
anyway. But at least it would be simpler.
Comment 5 wqtnetbeans 2005-03-21 19:27:35 UTC
I thought the whole purpose of removing the custom task of copyfiles was to to
make the build script runnable for "headless" users.... (My understanding -
check out and run, it should work.)

Anyway, isn't it true that, if the folder under which the jar files are stored
is in the same CVS working directory, all the refs to those jar files should be
"relative" paths in the In fact, I noticed the reference to
the same file appears in both the and the
(In my case, I have some 50 jar files all together like this.) 


In my, I have


The same jar file is referenced in as


Why can't the build script use the ones in, which are in
relative paths, rather than the ones in

Having to reconstruct the after c/o from CVS really defeats
the very purpose of removing the previous custom task.

Comment 6 Pavel Buzek 2005-03-21 20:46:17 UTC
As I said, this can and will be done for individual files. In this case I can
really use the properties defined in I will fix that soon.

The problem that remains (maybe not your problem) is with libraries and project
references where I do not have properties that I could use. A property can contain multiple file names.
Comment 7 wqtnetbeans 2005-03-21 21:52:23 UTC
Sorry I didn't understand the fact that individual files will be handled
properly. Only now I come to get your point about dependent libs and projects.
:) Maybe they can be handled in similar manner as with the individual files - If
lib or project jar file is within the same working CVS directory, use relative
path.... But I am just guessing. I am already pretty happy once the individual
files are done right. Thanks!!!
Comment 8 Pavel Buzek 2005-03-22 04:08:53 UTC
The most important part is fixed, the only case when are used
is for multifile libraries. Downgrading to P3.

cvs commit -m "56684 lib jar file refs in\n(only write into
private propertie..."
src\org\netbeans\modules\web\project\ui\customizer\ (in
directory C:\nb_all\web\project\)
Checking in src/org/netbeans/modules/web/project/resources/build-impl.xsl;
 <--  build-impl.xsl
new revision: 1.91; previous revision: 1.90
Checking in
new revision: 1.80; previous revision: 1.79
Comment 9 jimkatz 2005-05-15 02:29:56 UTC
Note also that when jar/lib files are removed from a project the references are
not removed from or, which causes the IDE
to report errors. This was with a standard java project.
Comment 10 Pavel Buzek 2005-08-25 05:54:05 UTC
Here is an idea: would it be possible to move these properties into in userdir where the libraries are defined? That would mean no
properties in It would also make synchronization easier and
the code could be in one place (not in every project like now) and synchronized
when the library changes. It could be even done in java\libraries code (?).
Comment 11 wqtnetbeans 2005-08-25 06:26:12 UTC
To me, all that matters is that I can work with NB on my Windows machine, check
in to CVS; check out from a Unix box (No NB installed, and I don't own the user
account from which the checkout is done. This is for nightly build....), and the
Ant script runs OK.
Comment 12 Tomas Zezula 2005-08-25 10:05:38 UTC
The problem with is that it makes shareability even worse for
users which have no NetBeans installation (an additional file is required).

But I've submitted a proposal to use relative paths anywhere where possible, all
paths stored in the project will be relative except of cross drive references
and libraries. Currenlty there is no consensus how to solve the problem with
libraries. One workable solution limits the library to single project (like
IDEA's project library) the second solution (library descriptor placed in any
folder) makes problems with shareability even worse for headless build and for
users who haven't NetBeans (it requires additional custom Ant tasks).
Comment 13 Jaroslav Pospisil 2006-03-13 13:43:04 UTC
TM 5.0->TBD
Comment 14 Pavel Buzek 2006-07-13 23:42:33 UTC
I do not think we will fix this for 5.5.
Comment 15 Petr Jiricka 2006-07-14 09:56:03 UTC
Looks like the proper fix needs to be done in the projects infrastructure, e.g.
issue 49638, right?
Comment 16 David Konecny 2007-09-27 11:55:41 UTC
I agree with you pjiricka. Whatever happens with 49638, web projects will need to replicate it. Not in 6.0.

Perhaps issue type should be changed to 'feature'.
Comment 17 Petr Jiricka 2007-10-01 16:52:09 UTC
Changing to feature.
Comment 18 David Konecny 2008-04-09 00:51:00 UTC
This should have been resolved as part of sharable libraries feature.