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.
When I upgrade a component library, the new library doesn't get used. It looks like the old library is still referenced even though the new one is added. Steps to reproduce: 1. Create a visualweb project. 2. Add the 0.1.1 AJAX complib. 3. Open the ui.jar->META-INF->rating->script.js and notice the declaration "new Array()". 4. Add the attached 0.1.2 complib to NetBeans and do a library-> update on the 0.1.1 library. 5. Do a clean build and notice the same script.js file in the "build" directory that has not changed. The new 0.1.2 complib uses "{}" instead of the "new Array()".
Created attachment 43270 [details] 0.1.2 complib
A workaround is to delete all complibs from the project and delete the "ui.jar" references from the library node. Then close the IDE and delete the userdir. Open the IDE and readd the new complib to the project.
A different workaround is to undeploy the app. Do a clean build and then re-deploy the app. That worked for me.
Looking at Lark's comment and trying this myself, I'm guessing that the Platform is "Windows" and not Mac as in the bug report. On Windows, when I do a "clean build", I get an error: Deleting directory C:\cygwin\home\edwingo\NetBeansProjects\WebApplication57\build C:\cygwin\home\edwingo\NetBeansProjects\WebApplication57\nbproject\build-impl.xml:781: Unable to delete file C:\cygwin\home\edwingo\NetBeansProjects\WebApplication57\build\web\WEB-INF\lib\appbase.jar BUILD FAILED (total time: 17 seconds) The reason is that the appserver has the jar file locked. So that explains why Lark's workaround helps. If this is indeed the problem, then the bug is in the "Clean build" action and not with component libraries. The "Clean build" should undeploy the app before doing the clean. I'm not sure who to reassign to so I will redirect to Po-Ting since he might know. There is probably another bug filed on this issue so it's probably a dup.
Looks like we have many issues that are related to "Server is locking some files in the project so that users cannot Remove, Move, Copy, Upgrade, ... the projects". All of these issues can be simply resolved by 'UNDEPLOY' the project before 'CLEAN' the project. If the web project owner dose not think this is the right behavior, then please reassign it back to visualweb/component. Thanks!
The original defect did indeed occur on the Mac OS X platform. The file locking was not the issue. Please try the "Steps to reproduce:" on a platform with a real filesystem like Solaris or Linux. Changing back to visualweb/components.
Lark: did you test this on a Mac or Windows? I don't have a Mac so it will take some time for me to test this.
windows only.
Lark: do you have access to a mac?
I'll send you an email with a link to one.
I was able to reproduce on a Mac. The bug is in web/project and does not require visualweb. A simpler test case is to create two different jar files with the same name like "foo.jar" in different directories and create two library definitions: "MyLibarary1" and "MyLibrary2". Then create a web project and add "MyLibrary1", then build the project. Look in the "/build/web/WEB-INF/lib" directory and see the first "foo.jar". Now, in Project Properties, remove "MyLibrary1" and add "MyLibrary2" and "Build". If you look in the "/build/web/WEB-INF/lib" then you still see the first "foo.jar" and not the one from "MyLibrary2". It appears that the code will not overwrite jars with the same name even if they are different. I will attach a zip file containing two different "foo.jar" files to help the engineer reproduce this bug. I do not know who to assign this to so I will leave it blank -- I can't leave it blank so I will guess. Also, there is a workaround: after updating or replacing a component library which is built on top of NetBeans Libraries, the user should do a "Clean and Build".
Created attachment 45274 [details] Zip file containing two jars with the same name
It was originally reported on a Mac, but it probably also happens on all platforms so I will change it to reflect that.
Assigning to Tomas. How often will the user need to do this in practice? Since there is a simple workaround, I would say the priority is probably P4.
I agree with Petr, changing to P3.
moving opened issues from TM <= 6.1 to TM=Dev
Moving to later
NetBeans.org Migration: changing resolution from LATER to WONTFIX