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.
After 3b24c68e8499, if you consent to installing libs.junit4 and junitlib in your IDE, these two modules are unpacked into the appropriate clusters (platform and java, resp.), and enabled; libs.junit4 as an autoload, junitlib as a visible regular module. "JUnit" (junitlib) appears in Plugin Manager as an enabled feature as expected. If you now select "JUnit" and ask to Uninstall it, and agree to restart the IDE, you will find that junitlib has been deleted from the java cluster as expected; but libs.junit4 remains in the platform cluster (now disabled). libs.junit4 ought to be deleted once its last remaining "client" is deleted, so that Uninstall is symmetric to Install, and so that a user intending to remove JUnit from their NB installation will really be doing so. Only apparent workaround is a manual cleanup: rm platform/config/Modules/org-netbeans-libs-junit4.xml platform/update_tracking/org-netbeans-libs-junit4.xml platform/modules/org-netbeans-libs-junit4.jar platform/modules/ext/junit-4.8.2.jar
Asymmetry is not a bug. Definitely not P2. I have more urgent things to do.
(In reply to comment #1) > Asymmetry is not a bug. Yes it is. As specified in http://wiki.netbeans.org/NB6AutoupdateChanges#Change_outline "Handling of kit module means handling all directly or indirectly depending modules at once. With the exception of no-visible modules which are currently depending to another kit modules." where junitlib here is the kit and libs.junit4 is the invisible module. Example C1 also illustrates this with reference to uninstallation. > Definitely not P2. Depends on your criteria. Two obvious effects of this bug: 1. During manual testing of the JUnit download scenario, if you agree to install JUnit, and then want to uninstall it to recheck the IDE's initial state, you cannot do this just by using Plugin Manager in the target platform; you need to manually remove files from the platform cluster. 2. If a user installs JUnit accepting the CPL but later changes their mind and asks to uninstall it, they will still have JUnit in their IDE, which was clearly not their intent.
Worksforme, if I create a module1 depending on autoload module2 (ie. invisible in PM). Both will installed together. If I uninstall module1, autoupdate uninstalls module2 too. (In reply to comment #2) > 1. During manual testing of the JUnit download scenario, if you agree to > install JUnit, and then want to uninstall it to recheck the IDE's initial > state, you cannot do this just by using Plugin Manager in the target platform; > you need to manually remove files from the platform cluster. I see you expecting libs-junit4 will be uninstalled. But, some other (autoload) modules depends on libs-junit4, e.g. o-n-m-jellytools-platform.jar, o-n-m-java-hints-test.jar etc. That's the reason why junit4 remains once it was installed. To solve this problem Autoupdate might check if all modules depending upon junit4 are disabled. If so, Autoupdate uninstalls junit4 regardless these modules are depending upon junit4. Do you think it makes sense to make Autoupdate stronger? Thanks > 2. If a user installs JUnit accepting the CPL but later changes their mind and > asks to uninstall it, they will still have JUnit in their IDE, which was > clearly not their intent.
Created attachment 118212 [details] a patch what considers state of dependent modules I tried to patch it and the patch works reasonable. I'm going to apply it tomorrow. I hope it doesn't create a regression somewhere.
(In reply to comment #3) > Worksforme, if I create a module1 depending on autoload module2 (ie. invisible > in PM). Both will installed together. If I uninstall module1, autoupdate > uninstalls module2 too. > > (In reply to comment #2) > > 1. During manual testing of the JUnit download scenario, if you agree to > > install JUnit, and then want to uninstall it to recheck the IDE's initial > > state, you cannot do this just by using Plugin Manager in the target platform; > > you need to manually remove files from the platform cluster. > I see you expecting libs-junit4 will be uninstalled. But, some other (autoload) > modules depends on libs-junit4, e.g. o-n-m-jellytools-platform.jar, > o-n-m-java-hints-test.jar etc. That's the reason why junit4 remains once it was > installed. > > To solve this problem Autoupdate might check if all modules depending upon > junit4 are disabled. If so, Autoupdate uninstalls junit4 regardless these > modules are depending upon junit4. Do you think it makes sense to make > Autoupdate stronger? > Thanks I tested the patch which makes Uninstall action more "destructive" but I found out a opposite case where the patch failed. So, I left the code as it, it means AU takes in account dependencies on currently disabled modules. > > 2. If a user installs JUnit accepting the CPL but later changes their mind and > > asks to uninstall it, they will still have JUnit in their IDE, which was > > clearly not their intent.
(In reply to comment #5) > I found out a opposite case where the patch failed. Specifically?
(In reply to comment #6) > (In reply to comment #5) > > I found out a opposite case where the patch failed. > > Specifically? Full ergonomics IDE w/ the patch, fresh userdir. 1) Uninstall PHP 2) Invoke activate Java => Cannot be activated because maven.kit has a dependency on some missing module. The same scenario works correctly on same IDE w/o the patch.
I guess the problem here is that we distribute "modules" like jellytools which are only intended for use in tests, for the benefit of Ant-based NBM suites; would be better if these behaved more like Maven-based projects and retrieved test dependencies on demand rather than requiring them to be part of the target platform.