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.
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.
Wrong component (probably).
Can you describe what is the problem? Does it really cause any trouble? How can I reproduce it?
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.
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.
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.
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.
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!!!
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
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.
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 (?).
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.
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).
TM 5.0->TBD
I do not think we will fix this for 5.5.
Looks like the proper fix needs to be done in the projects infrastructure, e.g. issue 49638, right?
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'.
Changing to feature.
This should have been resolved as part of sharable libraries feature.