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 private.properties
Summary: lib jar file refs in private.properties
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: David Konecny
URL:
Keywords:
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:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

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
project.properties and private.properties. And the build-impl.xml file is using
the refs in private.properties. 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
.../${some.ref.in.private.properties}"

I think the reason is that the build-impl.xml is taking the file refs in
"private.properties" rather than the ones in "project.properties". IMO those
refs should not be put into "private.properties" 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 private.properties.

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 private.properties 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 build.properties file. I
think this would be possible, but need comment from Tomas.
(Tomas, the private props web project now stores are like:
libs.jstl11.classpath.libfile.1=C:\\nb_all\\nbbuild\\netbeans\\enterprise1\\config\\TagLibraries\\JSTL11\\standard.jar
libs.jstl11.classpath.libfile.2=C:\\nb_all\\nbbuild\\netbeans\\enterprise1\\config\\TagLibraries\\JSTL11\\jstl.jar
)

Note that if you have a library in your project the IDE has to know the location
of netbeans userdir anyway to load the build.properties - this is stored in
private.properties - so it would not work completely w/o private.properties
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 project.properties? In fact, I noticed the reference to
the same file appears in both the project.properties and the private.properties.
(In my case, I have some 50 jar files all together like this.) 

ex.

In my project.properties, I have

file.reference.axis.jar=../../Telescope/lib/axis.jar

The same jar file is referenced in private.properties as

file.reference.axis.jar.libfile.1=C:\\wqt\\vcs\\nb41\\tel-web-ube\\Telescope\\lib\\axis.jar

Why can't the build script use the ones in project.properties, which are in
relative paths, rather than the ones in private.properties?

Having to reconstruct the private.properties 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 project.properties. 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
lib.xyz.classpath 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 private.properties are used
is for multifile libraries. Downgrading to P3.

cvs commit -m "56684 lib jar file refs in private.properties\n(only write into
private propertie..."
src\org\netbeans\modules\web\project\resources\build-impl.xsl
src\org\netbeans\modules\web\project\ui\customizer\WebProjectProperties.java (in
directory C:\nb_all\web\project\)
Checking in src/org/netbeans/modules/web/project/resources/build-impl.xsl;
/cvs/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl,v
 <--  build-impl.xsl
new revision: 1.91; previous revision: 1.90
done
Checking in
src/org/netbeans/modules/web/project/ui/customizer/WebProjectProperties.java;
/cvs/web/project/src/org/netbeans/modules/web/project/ui/customizer/WebProjectProperties.java,v
 <--  WebProjectProperties.java
new revision: 1.80; previous revision: 1.79
done
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 private.properties or project.properties, 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
build.properties in userdir where the libraries are defined? That would mean no
properties in private.properties. 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 build.properties 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.