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.
Summary: In a NetBeans Platform Appplication, JARs removed from Wrapped JARs (that remain in release/modules/ext) are used instead of JARs from Wrapper Library Modules. Steps to Reproduce: Steps assume you have a standard Java Application project which you can modify and build JARs from. This will be a library for our NetBeans Platform Application and the resulting JAR is referred to below as the "library JAR". I suggest making a class with a static method which just returns a string. 1) Create a new NetBeans Platform Application. 2) Create a new Module in it. 3) Add the library JAR to the module's Wrapped JARs tab under Libraries. 3) Make an Installer in the module that makes use of a class in the library JAR. 4) Run the application and note the results. 5) Suppose now we decide that it is not good practice to use Wrapped JARs and that we will use a Library Wrapper Module instead. 6) First make a change to your library - one you will notice when the module runs again. Rebuild the library JAR. 7) Remove the library JAR from Wrapped JARs using the GUI (Properties > Libraries > Wrapped JARs > Remove button). Note your module no longer compiles as expected. 8) Create a new Library Wrapper Module referencing the library JAR. 9) Add the Library Wrapper Module to your module under Libraries > Module Dependencies. 10) Your module now compiles, but when it is run, you notice the changes made in step 6 are not there. What is happening is that the library code is taken from the removed Wrapped JAR in the module's release/modules/ext directory rather than from the dependency on the Library Wrapper Module. If you delete the JARs in the module's release/modules/ext directory, then the correct code from the Library Wrapper Module is run. Build Date & Platform: Product Version: NetBeans IDE 7.0 (Build 201104080000) Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01 System: Linux version 2.6.32-31-generic running on amd64; UTF-8; en_CA (nb)
This is a user error - you should delete the JAR from the module which is no longer using it - but ought to be detected by the harness. The lib wrapper module is built first (for dependency ordering reasons), and copies its JAR to the cluster, marking itself as the owner. Then the regular module is built, and overwrites the JAR (since it has the same cluster-relative path), marking itself as the owner. Somewhere along the line, the harness needs to report this as an error. org.netbeans.nbbuild.DeleteUnreferencedClusterFiles would accomplish this but is not currently included in the harness.
You're right that unused JARs should be removed by a module once they are no longer used, so why does NetBeans leave the JAR around in release/modules/ext? I don't think it's fair to call it a user error because the user *did* delete the unused JAR from the module. Look at it from the user's perspective. They added the JAR in the Wrapped JARs panel and then deleted it from there too. If it doesn't show up in the Wrapped JARs panel and any code that makes use of the JAR doesn't compile, then it's gone, right? The user doesn't know or shouldn't need to know that the JAR was never actually deleted from the file system and is lying to wait to be resurrected as an imposter once the module is made dependent on a library wrapper module. :) This bug isn't important to me because I'm aware of it now. But I think it is important for usability for new users. It was one of the first problems I ran across and I think what I did is fairly common when starting out with the platform, i.e. create a new NetBeans Platform Application and just add your existing Java project as a Wrapped JAR; then later realize that you should be using the Library Wrapper Module instead. But anyways, isn't it easier to just delete the JARs from release/modules/ext?
(In reply to comment #2) > why does NetBeans leave the JAR around in release/modules/ext? As mentioned in the other issue, GUI customizers generally do not go deleting files; too dangerous. While you may think it is fine, someone else will be shocked that removing a reference to a JAR actually deleted it too. Can probably issue some warning in the GUI.
It's up to you but the JARs in release/modules/ext are always just copies of other JARs so I don't know why anyone would care if they're deleted. If you're worried about symbolic links, you could check for that.
(In reply to comment #4) > JARs in release/modules/ext are always just copies of other JARs Not necessarily. > If you're worried about symbolic links No, File.delete() would only delete the link.
When are they not? The GUI doesn't even give an option to reference a JAR directly, it always makes a copy of it under the module's directory structure. If someone deletes the original JAR elsewhere, then sure they might have a problem if somehow the can't get a copy of the JAR from anywhere, but how likely is that? I can see the user might be annoyed if they delete the JAR because they mistakenly believe they no longer have any dependencies and then want to re-add it immediately after seeing the compile errors, but that should be just a minor time cost. I don't agree that it's too dangerous for GUI customizers to delete files. Maybe something very bad happened in NetBeans in the past? :) The GUI deletes information from layer.xml for example. When the information is deleted, it's gone to the user; whether it was contained within some other file or was stored in its own file is an implementation detail. The end result to the user is the same. NetBeans has (nicely) abstractly the file system and has provided different implementations of disk, JAR, and XML so it's funny that in it's programming it's still making a distinction. Another idea would be to just move the removed Wrapped JARs to some trash directory or something. That way the bug above wouldn't occur and if a user does realize they want the JAR back, they can easily find it. Another option, like you said, would be to ask the user when they click Remove if they want to delete the JAR from the file system or not. Of course if you allow the user to keep it, you still have to take care of the bug above using the other methods you mentioned.
(In reply to comment #6) > When are they not? Some may update a JAR directly in release/modules/ext. This is pretty common actually. > The GUI doesn't even give an option to reference a JAR directly Right, due to weakness in the Ant harness. Note that Maven-based NBM development does not suffer from this issue since you simply add a dep on the non-NBM artifact. > I don't agree that it's too dangerous for GUI customizers to delete files. I can assure you that screaming P1 bugs will be filed by people who neglect to check in their work to an SCM often enough. :-) > The GUI deletes > information from layer.xml for example. When the information is deleted, it's > gone to the user Not via Local History. Anyway there is some kind of threshold in terms of size and complexity of things that can be deleted without serious confirmation. > Another option would be to ask the user when they click Remove > if they want to delete the JAR from the file system or not. Mentioning that in bug #199004.
> Some may update a JAR directly in release/modules/ext. This is pretty common actually. Yeah, I'm doing that myself, but in that case you can just rebuild the JAR. To be clear, since JARs are basically secondary artifacts, I don't see the big deal in deleting them. Thanks, Jesse.
Can the reporter provide me a project with easy steps to reproduce the problem?