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.
If I have a project that depends on a library named "library" which I define using the Library Manager, then NetBeans will insert a reference to "lib.library.classpath" in the nbproject/project.properties file. However, if I ever edit the definition of "library" in the Library Manager... the changes will never be filtered back to the ant project.properties file. I suggest that the default behaviour be to automatically filter any changes in "library" back to the ant properties file, for all open projects.
Reassigning to "projects" for evaluation.
> suggest that the default behaviour be to automatically filter any changes in "library" back to the ant properties file, for all open projects. With a few days of thought about how this would work... I'd now shy away from asking that this be default behaviour. It may be troublesome in a team. It would, however, make a lot of sense to have the options to:- - update a project's libraries to reflect a local setup - update all project libraries to reflect a local setup - update a local setup based on a project's libraries (where local setup means the Library Manager's list of jars, sources and javadocs) and these options could be hidden unless relevant. To do the source/javadoc synching, the path within source/javadoc archives may need to be stored in the project.properties file. This may be resolved when issue 44035 is resolved... but it may be worth keeping in mind that project descriptors may become out of date with the local descriptor and other projects fairly quickly.
sounds strange, what kind of project is it (web, j2seproejct, j2ee)? By default the libs.<name>.classpath is added into build.proterties in your user dir and is updated every time you edit the library in the library manager and on every start of the IDE (tracks external modifications). But several project types started to rewrite this property into the private.properties which may cause this problem. Can you verify if you have libs.<name>.classpath defined in the nbproject/project.properties or nbproject/private/private.properties
tzezula, I'm afraid I can't ceck this for you because it was such a critical issue that I resolved it by manually removing the libraries from the projects and then adding them again! (I had to close down the project properties dialog between removal and re-entering or else nothing changed). I can confirm that the projects were J2SE projects. The issue may have arisen because my hack around issue 124779 is to edit the library XML definition on the command line (to add the archive path within sources and javadocs).
Thanks, even the project type is very helpful I will not need to check all of them. The workaround of #124779 shouldn't have effect on it.
tzezula: were you able to reproduce this? I'm still seeing it in 6.0.2 and have just been stung again... removed some jars from a Library and none of the projects that reference it were updated... they still depend on the old version. The only workaround is to removed the library dependency and exit the project properties editor, then re-enter and add the library again.
update: sorry, this time it did actually work as expected... I was looking at the wrong project! Still, it definitely happened as described below on at least one occasion for me. If you are unable to reproduce, then perhaps it has something to do with the fact that I was manually editing the XML descriptor files when NetBeans was open.
more update: nope, it did break... I edited the Library descriptor of a library in "Tools -> Libraries", removing some jar files. A project which depended on this library at compile time *was* updated. However, all the projects that only had this library in their runtime classpaths, *did not* get updated. Perhaps that will help you to reproduce the bug.
also... even when my local definition of the library was updated, it was only updated in nbproject/private and not in nbproject/project.properties... so it breaks the ant build scripts.
Thanks very much for your investigation. It seems that the code which listens on Libraries changes updates only private.properties. The question is if the code is still needed now when project (shared) libraries were integrated. The code was trying to simulate the project libraries but it never worked correctly. Probably the best thing is to remove it completely, if the Library is global nothing will be rewritten into project (private) properties, the shared libraries should be used for this.
I don't know how the new local Library updates will be managed, but it is certainly true that I'll be using sharable libraries from now on and this won't affect me. If this bug still affects single users with local Library descriptors, then I'd suggest that it be fixed. However, I'm not all that fussed. Can't wait for 6.1 now :-)
The library path is no more rewritten into the project.properties nor private.properties, non needed due to shareable libraries.