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.
original initiator: iformanek Besides "Disable Module", there should also be an action for actual uninstallation of a module. Although disabling is effectively the same as uninstall, the module is still lited in the list of installed modules, and its files might be located in the userdir. If the user is sure he does not want this module, there should be an option to get rid of it completely.
keyword UI added
*** Issue 19346 has been marked as a duplicate of this issue. ***
Auto Update issue; the module system cannot just get rid of the files. If you install a module as JAR from an ad-hoc location you can already delete it from the UI. It is removed from the list of modules. This cannot happen if it is in the modules/ directory because it would need to really be deleted on disk -> problem for AU.
Jesse, do you mean it's only AU task? OK, so what do you think AU should do? - allow Delete action on Tools -> .. -> Modules even for standard modules Inside Delete: - delete module.jar (and possibly other module entries) - do some unregistration of module from module list? How? - other action? Thanks
Yes, I think it must be implemented in AU. ModuleNode needs to provide a hook similar to its current NewType hack to let normal modules be deletable, but that is all. First, simply delete the XML file from the Modules/ folder in SFS: this ought to work to disable it incl. all dependencies, and remove it from the available module list. Second, delete all files in the installation which update_tracking.xml mentions, incl. the module JAR.
Hi Jesse, working on this I tried to delete module.jar (from OS, from IDE..) after disabling module and that's not possible. I guess there remains something not released, probably module classloader? Do you think it will be possible to release it during Disable module to be module.jar deletable? Or do you have some other idea? Thanks, -Ales
I guess you are using Windows, not Unix. Check the log file. If it says "Warning: not all resources from such-and-such-module were released", that is your problem. Normally they get released sometime later. So long as we use ResourceBundle, due to a JDK bug it is impossible to guarantee module JARs are releasable. Even if we don't, if there is any bug in a module whereby it does not remove every last object from the running VM when uninstalled, or does but only after a delay - this is pretty common really, sometimes the module cannot help it because of core timing issues - then there is no possibility to GC the module classloader immediately, thus no possibility to modify/destroy the JAR on Windows. When using test modules, everything is loaded from a copy of the JAR, thus there is no problem. With regular modules though, you cannot be sure when the classloader will be released. I don't know exactly what to say, other than maybe you can leave some info on disk for the updater.jar to delete things later after the IDE shuts down (but without then restarting the IDE).
Forgot: use -J-Dorg.netbeans.core.modules=0 to get the interesting messages in the log file.
Now that I think about it, it may be possible to unlock the JAR forcibly. I was still thinking about URLClassLoader, but in fact for modules we now use a custom JarClassLoader whose behavior we control. It can "know" when the module has been not only disabled but is actually about to be deleted; i.e.: ModuleManager.delete(Module) has been called to remove the entry for the module from the system, and autoupdate intends to delete the JAR soon. In this case, JarClassLoader could close the JarFile's it holds: the module plus any patches and extensions and locale variants. (URLClassLoader does not provide API access to its JarFile's.) That would ensure that the JAR was deletable. The danger is that code from the module might still be running - e.g. unclosed TopComponent's, or posted requests, or a loader in the loader pool which has not yet been removed... If any such code attempts to load classes from the now-closed (and maybe deleted) JAR, a NoClassDefFoundError will result. It might be possible in case a module is about to be deleted to create a copy in /tmp (File.createTempFile) of all the JARs the classloader had open, open the copy JARs, close the originals, and switch the JarFile's used internally. Also, if and when the classloader is finalized, close the copy JARs and delete them. Not particularly efficient, but should be safe, and after all modules are not all that frequently deleted: besides this AU feature, the user can only delete modules which were installed "ad-hoc" (from a random JAR). Does it sound like this approach would be helpful? If so, I can try to implement it. Just assign a task to me: core/modules P2 ENH "Release all JarFile locks when ModuleManager.delete called"
I created issue #21114 for Jesse
desirable request, but we may not have enough resource to work on it for 3.4. Lowered prio to P3
Target milestone was changed from '3.4' to TBD.
*** Issue 26299 has been marked as a duplicate of this issue. ***
reassigne to Hrebejk, new owner of autupdate
IMHO this is the most important issue in autoupdate - a very common user complaint and source of confusion/frustration. Furthermore it should not be all that difficult, I think.
This feature is very important from the perspective of Module Catalogue and partner offerings. A typical scenario involves user downloading a module to try it, and after realising he does not want to use it, trying to figure out how to uninstall. This is a very high priority feature for the next NetBeans release.
Suggest this be scheduled for 3.5.
reassigne to Jirka - new owner of autoupdate
Clearly this did not make it for 3.6. :-(
*** Issue 41482 has been marked as a duplicate of this issue. ***
Nor for promo-D.
*** Issue 45903 has been marked as a duplicate of this issue. ***
Trung, please consider this seriously for E.
This issue needs to be adressed urgently! I am considering uninstalling Netbeans 3.6 as I installed a crappy module which practically took mover the whole UI. PLEASE RESOLVE QUICKLY!
johnmuir: Shut down, delete the module JAR from the modules/ subdirectory of your user directory (or wherever you installed it), and restart; the module should be gone. Or you can just disable it in the Modules tab, probably enough in your case. Please use nbusers for support questions in the future.
*** Issue 27296 has been marked as a duplicate of this issue. ***
This funtionality ios very much needed. Sincve the installation is a usr-level task, the module uninstallation should not require hacking with configuration files on disk. The profiler project recently encountered several situations, where, due to other bugs in the module system or bugs in profiler module code, the users were unable to upgrade and had to do uninstall to be able to install a newer milestone release. Ant the uninstall instructions are really complex. Here is example of the instructions that I just today sent out to users: 1. exit the IDE 2. delete $userdir/modules/zorg-netbeans-modules-profiler.jar 3. delete $userdir/ant/nblib/org-netbeans-modules-profiler.jar 4. delete $userdir/docs/profiler 6. delete $userdir/modules/autoload/profiler.jar (if exists) 7. delete $userdir/modules/eager/org-netbeans-modules-profiler-*.jar 8. delete dirs $userdir/modules/profiler-ea-* Perhaps the time has come to do something about it. I filed this issue three years, ago, there were votes, numerous duplicates filed since, and even the P2 priority suggests that this is important.
Hi Ian, I beleive you should become a NetCAT participant, IssueZilla simply doesn't work in netbeans.org project, imho.
This task has been added to NetBeans Feature Plans for promoF.
As a user who had to manually uninstall the first milestone build of the profiler, I agree that the ability to Uninstall a module is long overdue!
Created attachment 22010 [details] 1st draft of uninstall implementation
I attached 1st draft of implementation. core/modules/Module handles the removing of all files connected to deleted module. The list of module's files is read from module's update_tracking.xml file. Uninstallation works for global and local installation. The write permission should be checked before file deletion. UI of this action needs improvement. This attachment contains only a prototype future implementation.
I believe this functionality should be handled in autoupdate, not core, except with small hooks added to core if and when necessary. Definitely it should not be part of Module (which will be moved to boot.jar). ModuleList in core should be reacting to the removal of a config/Modules/*.xml entry by unloading that module. See ModuleList.Listener.stepDelete. Apparently this is not working at the moment, so that should be fixed (and tested). When it is, autoupdate can simply remove all the NBM's files (which must include the module XML config file, or it would never been present to begin with) and the module should quietly disappear. BTW in my informal tests, it seems that [org.netbeans.core.modules] ModuleList: outside file deletion event for org.netbeans.modules.foo is never called. This might mean a bug in filesystems, since ModuleList adds a file change listener to the Modules folder.
Correction: I investigated and filed issue #58663. It seems that just deleting the config/Modules/*.xml file on disk is not sufficient, even after triggering a general IDE refresh (by giving it focus). However it ought to work fine if you either 1. Use FileObject.delete() to remove this file. 2. Or, make all changes on disk but call FileObject.refresh() on nbfs:///Modules/ to notify ModuleList of your changes. AU is already capable of *adding* a module to the IDE simply by installing the correct files and triggering a FS refresh. It should use precisely the reverse steps to *remove* a module. I do not believe any special support from core should be necessary. So the current patch should probably just be thrown out. Note #1: AU should search for installations of an NBM in all clusters (+ user dir) and delete any and all instances it finds, if the user requests a deletion. I guess. Note #2: if ModuleList receives a deletion event for module A, and module B depends on A (both enabled), it will just delete A and disable B. No problem.
Thanks Jesse for hints. Me comments are bellow: > I believe this functionality should be handled in autoupdate, not core, except with small hooks added to core if and when necessary. Yes, autoupdate module could handle this functionality (removing files as a matter of Uninstall action) but Autoupdate in the current state provides no UI where to hang Uninstall action. For now, the ModuleNode should own this action which calls autoupdate code via some hook. If module catalog UI would be moved to autoupdate (issue 26208) then the UI will cleaner. > Definitely it should not be part of Module (which will be moved to boot.jar). Sure. > ModuleList in core should be reacting to the removal of a config/Modules/*.xml entry by unloading that module. It quite works, however needs to force refresh of ModuleList, FileObject.delete() isn't enough but it can be fixed. If the list is refreshed then rest of action works right. I'll push for autoupdate removes files, the rest of works (to disable an module, module dependencies handling) does the module system. I'm going to prepare next prototype in this way. Thanks for comments.
Re. lack of issue #26208 - yes, but AU *already* adds hooks to the Modules node (for Add NBM...), so for now we can probably handle this the same way - register a deletion hook. FileObject.delete() doesn't force a refresh of ModuleList? Really? Works for me: install apisupport (+ apisupport/lite + utilities/group) and sysprops; in Bean Browser, delete org-netbeans-modules-sysprops.xml; module is correctly removed. But as mentioned in #58663, you currently need to do the delete in SFS, not using FileUtil.toFileObject(...).delete() - a bug but easily worked around.
Created attachment 22128 [details] 2nd prototype
I attach 2nd prototype it's with regard to proposed hints. Most of handling of uninstallation has been moved to Autoupdate. Hook to Module's UI is done by declaration as module's services. I'm going to add some UI of this action, polish the code and then I'll ask for review.
I'm not sure what you're trying to accomplish with the second patch. There should be no need for a patch to ModuleBean. Rather, UninstallModulePerformer (prefer rename to e.g. ModuleDeleter) should have methods: boolean canDelete(ModuleInfo module); void delete(ModuleInfo[] modules) throws /* e.g. */ IOException; The UMP impl in AU should return true for canDelete iff AU knows about such a module, and it is not installed in the lib/ or core/ dirs. delete() should simply remove the NBM files, as you have already written. Now ModuleNode can look for a UMP in lookup (use Lookup.gD().lookup(UMP.class), no need for Lookup.Template here!), and behave as follows: 1. Enable canDestroy() on a module node iff (ump != null && ump.canDelete(item.getModule())) || item.getJar() != null 2. Impl destroy() as if (ump != null && ump.canDelete(item.getModule())) { ump.delete(new ModuleInfo[] {item.getModule()}); } else { item.delete(); } This will have the desired effect: 1. A module which corresponds to an installed NBM (if AU is enabled) can be deleted, by removing all the NBM's files, which will of course also cause the module to disappear from the loaded set in memory. 2. A module which is not part of any NBM (or if AU is disabled) but which is loaded in normal module from a specified JAR (i.e. it has a config/Modules/*.xml entry) can be deleted by just removing the config/Modules/*.xml entry (which will also cause the module to disappear from the loaded set in memory). This is normally the case for manually added modules, modules loaded in test mode, etc. 3. Modules loaded from the startup classpath cannot be deleted.
> (prefer rename to e.g. ModuleDeleter) should have methods: > > boolean canDelete(ModuleInfo module); > void delete(ModuleInfo[] modules) throws /* e.g. */ IOException; Ok, looks better. An decision true/false method will be useful. > > The UMP impl in AU should return true for canDelete iff AU knows about such a > module, and it is not installed in the lib/ or core/ dirs. delete() should > simply remove the NBM files, as you have already written. > > Now ModuleNode can look for a UMP in lookup (use Lookup.gD().lookup(UMP.class), > no need for Lookup.Template here!), and behave as follows: Depends if I'll listen on Lookup.Result on the Autoupdate's enable/disable state. Perhaps I won't. > 1. Enable canDestroy() on a module node iff (ump != null && > ump.canDelete(item.getModule())) || item.getJar() != null > > 2. Impl destroy() as > > if (ump != null && ump.canDelete(item.getModule())) { > ump.delete(new ModuleInfo[] {item.getModule()}); It will work but it breaks that the SetupWizard is cancelable, it has been the only reason why I patched ModuleBean instead of ModuleNode. I suppose we can omit it if new ModuleCatalog will replace this panel in SetupWizard. > } else { > item.delete(); > } > > This will have the desired effect: > > 1. A module which corresponds to an installed NBM (if AU is enabled) can be > deleted, by removing all the NBM's files, which will of course also cause the > module to disappear from the loaded set in memory. It means that only modules installed by AutoUpdate can be uninstalled (e.g. deleted from disk)? I've been assumed that any module (regardless it's from standard distribution or not) can be deleted. Should be this action restricted only on modules for NBMs? In this case some explicative UI is needed, users could be confused by different results from same action. Anyway, thanks for comments I'll modify the prototype with regard to those . > 2. A module which is not part of any NBM (or if AU is disabled) but which is > loaded in normal module from a specified JAR (i.e. it has a config/Modules/*.xml > entry) can be deleted by just removing the config/Modules/*.xml entry (which > will also cause the module to disappear from the loaded set in memory). This is > normally the case for manually added modules, modules loaded in test mode, etc. > > 3. Modules loaded from the startup classpath cannot be deleted.
Yeah, just delete that panel from the Setup Wizard. (We can probably delete the whole wizard for that matter; I don't know why it's still there at all.) Yes, I think this feature (actual file deletion) should be restricted to modules installed from NBM. If a module is not from NBM, you don't know anything about it except where the JAR is, so all you can do is remove the module's registration (config/Modules/*.xml, which will very likely be in the userdir). Don't put in any explanatory UI (IMHO); no need. People don't want to think about it. They just want to delete a module and have the IDE do the right thing. No reason that I can think of to listen to any Lookup.Result.
> (We can probably delete the > whole wizard for that matter; > I don't know why it's still there at all.) P.S. If you do delete the wizard, don't forget to remove the references from documentation.
> Yeah, just delete that panel from the Setup Wizard. Jesse is right. Go ahead and remove the Modules pannel. The whole Setup Wizard will most likely follow.
> Yeah, just delete that panel from the Setup Wizard. (We can probably delete the > whole wizard for that matter; I don't know why it's still there at all.) Ok, I won't stress about it. I suppose that impl. of the AutoUpdate UI spec. (with new Module Catalog) is targeted to promoF. > Yes, I think this feature (actual file deletion) should be restricted to modules > installed from NBM. If a module is not from NBM, you don't know anything about > it except where the JAR is, so all you can do is remove the module's > registration (config/Modules/*.xml, which will very likely be in the userdir). Not fully true. I can use the update_tracking files which are generated for each module in product distribution. Anyway it's not important in this phase of implementation. ModuleDeleter.canDelete() controls if a module may or may not be deleted. If we would decide to delete also modules from original distribution then no problem, canDelete() can allow it.
I guess I wasn't clear. By "installed from NBM" I mean any module which has an update_tracking/*.xml entry in either the userdir or some registered cluster - which would of course include all modules in the distribution.
Created attachment 22303 [details] 3rd draft
I attached next impl. draft 3rd, contains: the proposed interface ModuleDeleter, implemented in Autoupdate. DeleterImpl check if update_tracking is available for deleted module, if yes and the module isn't fixed the allow its deletion from disk. The deletion starts with config/Module/$module.xml - module system reflects it -> disable the module if needed, notified the list. Then the deletion continues with rest of file, ends with update_tracking. I also removed the ModuleSelectionPanel from SetupWizard (not needed but it works better). Please, review the patch. The change are on a branch, you can 'cvs checkout -fr uninstall_module_20323 core/src core/ui autoupdate ' and play with it. Thanks
Created attachment 22328 [details] merge candidate (w/o UI support)
I have some comments related to uninstall (most of them are related to the NetBeans Module System): 1.Since the problematic is not very clear it is highly appreciated to have UI-specification for module install/uninstall. 2.There may appear some weakness of Module System that may cause the NetBeans get broken - it is not possible to start netbeans (especially when module is installed and corrupts something). Therefore there should be some extra mechanism how to recreate the previous state of netbeans. There should be some "Safe Mode" - NetBeans command line option (or holding some key combination at the beginning of start procedure) that starts only "module management" - dialog where user disables those modules that caused destabilization. 3.Uninstalled modules should not be deleted. They should be stored by side so that: -they can be used by another user (when NetBeans started with clear userdir) -the user can specify whether the module is intended to be disabled in current userdir/global -the undo of uninstall can be supported 4.The progress of the action should be visible while the category of modules is being disabled/uninstalled. 5.The "delete" menu item should be substituted with "uninstall".
juhrik's #2, #3, and #4 are probably RFEs that should not block implementation of this feature.
OK, I have filed enhancements #60367, #60368, #60369 for these features.
I have a headache with uninstall feature on windows :-( Windows locks jar files of loaded module. I'm not able to delete module's files from user disk within IDE session if a module is/was enable. Possible solution if module jar is being locked: - disable the module if enabled (probably not needed, actions bellow can be enough) - use Autoupdate manner - Restart now or restart later i.e. - write to_delete.xml file which contains list of files to delete from disk in a directory, this directory will read the IDE launcher and determine if run AU Updater or not - Updater parse to_delete.xml file and delete matching files Restart only if needed (i.e. not on unix, not if the files aren't locked on windows). Any other ways how to achieve it? Thanks
The module system is *supposed* to release the JAR lock when a module is disabled. See JarClassLoader.releaseLocks. Please use a profiler to track who is holding onto the module's JarFile and correct the issue. There should be no need to restart the IDE.
Checking in jellytools/nbproject/project.xml; /cvs/jellytools/nbproject/project.xml,v <-- project.xml new revision: 1.9; previous revision: 1.8 done Checking in i18n/nbproject/project.xml; /cvs/i18n/nbproject/project.xml,v <-- project.xml new revision: 1.11; previous revision: 1.10 done Checking in core/manifest.mf; /cvs/core/manifest.mf,v <-- manifest.mf new revision: 1.44; previous revision: 1.43 done Checking in core/execution/nbproject/project.xml; /cvs/core/execution/nbproject/project.xml,v <-- project.xml new revision: 1.7; previous revision: 1.6 done Checking in core/ide/nbproject/project.xml; /cvs/core/ide/nbproject/project.xml,v <-- project.xml new revision: 1.8; previous revision: 1.7 done Checking in core/settings/nbproject/project.xml; /cvs/core/settings/nbproject/project.xml,v <-- project.xml new revision: 1.9; previous revision: 1.8 done Removing core/src/org/netbeans/core/ModuleNode.java; /cvs/core/src/org/netbeans/core/ModuleNode.java,v <-- ModuleNode.java new revision: delete; previous revision: 1.46 done Checking in core/src/org/netbeans/core/actions/Bundle.properties; /cvs/core/src/org/netbeans/core/actions/Bundle.properties,v <-- Bundle.properties new revision: 1.145; previous revision: 1.144 done Removing core/src/org/netbeans/core/actions/SetupWizardAction.java; /cvs/core/src/org/netbeans/core/actions/SetupWizardAction.java,v <-- SetupWizardAction.java new revision: delete; previous revision: 1.11 done Removing core/src/org/netbeans/core/modules/Bundle.properties; /cvs/core/src/org/netbeans/core/modules/Bundle.properties,v <-- Bundle.properties new revision: delete; previous revision: 1.15 done Removing core/src/org/netbeans/core/resources/setupWizard.gif; /cvs/core/src/org/netbeans/core/resources/setupWizard.gif,v <-- setupWizard.gif new revision: delete; previous revision: 1.1 done Checking in core/src/org/netbeans/core/ui/Bundle.properties; /cvs/core/src/org/netbeans/core/ui/Bundle.properties,v <-- Bundle.properties new revision: 1.77; previous revision: 1.76 done Removing core/src/org/netbeans/core/ui/IDESettingsPanel.form; /cvs/core/src/org/netbeans/core/ui/IDESettingsPanel.form,v <-- IDESettingsPanel.form new revision: delete; previous revision: 1.20 done Removing core/src/org/netbeans/core/ui/IDESettingsPanel.java; /cvs/core/src/org/netbeans/core/ui/IDESettingsPanel.java,v <-- IDESettingsPanel.java new revision: delete; previous revision: 1.42 done Removing core/src/org/netbeans/core/ui/IDESettingsWizardPanel.java; /cvs/core/src/org/netbeans/core/ui/IDESettingsWizardPanel.java,v <-- IDESettingsWizardPanel.java new revision: delete; previous revision: 1.6 done Removing core/src/org/netbeans/core/ui/ModuleBean.java; /cvs/core/src/org/netbeans/core/ui/ModuleBean.java,v <-- ModuleBean.java new revision: delete; previous revision: 1.36 done Removing core/src/org/netbeans/core/ui/ModuleEnableDisablePanel.form; /cvs/core/src/org/netbeans/core/ui/ModuleEnableDisablePanel.form,v <-- ModuleEnableDisablePanel.form new revision: delete; previous revision: 1.2 done Removing core/src/org/netbeans/core/ui/ModuleEnableDisablePanel.java; /cvs/core/src/org/netbeans/core/ui/ModuleEnableDisablePanel.java,v <-- ModuleEnableDisablePanel.java new revision: delete; previous revision: 1.8 done Removing core/src/org/netbeans/core/ui/ModuleNode.java; /cvs/core/src/org/netbeans/core/ui/ModuleNode.java,v <-- ModuleNode.java new revision: delete; previous revision: 1.36 done Removing core/src/org/netbeans/core/ui/ModuleSelectionPanel.form; /cvs/core/src/org/netbeans/core/ui/ModuleSelectionPanel.form,v <-- ModuleSelectionPanel.form new revision: delete; previous revision: 1.11 done Removing core/src/org/netbeans/core/ui/ModuleSelectionPanel.java; /cvs/core/src/org/netbeans/core/ui/ModuleSelectionPanel.java,v <-- ModuleSelectionPanel.java new revision: delete; previous revision: 1.25 done Removing core/src/org/netbeans/core/ui/ModuleSelectionWizardPanel.java; /cvs/core/src/org/netbeans/core/ui/ModuleSelectionWizardPanel.java,v <-- ModuleSelectionWizardPanel.java new revision: delete; previous revision: 1.3 done Removing core/src/org/netbeans/core/ui/NbLabelA11y.java; /cvs/core/src/org/netbeans/core/ui/NbLabelA11y.java,v <-- NbLabelA11y.java new revision: delete; previous revision: 1.1 done Removing core/src/org/netbeans/core/ui/NbTextAreaA11y.java; /cvs/core/src/org/netbeans/core/ui/NbTextAreaA11y.java,v <-- NbTextAreaA11y.java new revision: delete; previous revision: 1.1 done Removing core/src/org/netbeans/core/ui/SetupWizard.java; /cvs/core/src/org/netbeans/core/ui/SetupWizard.java,v <-- SetupWizard.java new revision: delete; previous revision: 1.17 done Removing core/src/org/netbeans/core/ui/WebBrowserPanel.form; /cvs/core/src/org/netbeans/core/ui/WebBrowserPanel.form,v <-- WebBrowserPanel.form new revision: delete; previous revision: 1.3 done Removing core/src/org/netbeans/core/ui/WebBrowserPanel.java; /cvs/core/src/org/netbeans/core/ui/WebBrowserPanel.java,v <-- WebBrowserPanel.java new revision: delete; previous revision: 1.5 done Removing core/src/org/netbeans/core/ui/WizardFolder.java; /cvs/core/src/org/netbeans/core/ui/WizardFolder.java,v <-- WizardFolder.java new revision: delete; previous revision: 1.16 done Checking in core/startup/src/org/netbeans/core/startup/ModuleList.java; /cvs/core/startup/src/org/netbeans/core/startup/ModuleList.java,v <-- ModuleList.java new revision: 1.2; previous revision: 1.1 done Checking in core/ui/src/org/netbeans/core/ui/resources/IDESettings.settings; /cvs/core/ui/src/org/netbeans/core/ui/resources/IDESettings.settings,v <-- IDESettings.settings new revision: 1.3; previous revision: 1.2 done Checking in core/ui/src/org/netbeans/core/ui/resources/layer.xml; /cvs/core/ui/src/org/netbeans/core/ui/resources/layer.xml,v <-- layer.xml new revision: 1.94; previous revision: 1.93 done Checking in core/windows/nbproject/project.xml; /cvs/core/windows/nbproject/project.xml,v <-- project.xml new revision: 1.10; previous revision: 1.9 done Checking in autoupdate/manifest.mf; /cvs/autoupdate/manifest.mf,v <-- manifest.mf new revision: 1.56; previous revision: 1.55 done Checking in autoupdate/arch/arch-autoupdate.xml; /cvs/autoupdate/arch/arch-autoupdate.xml,v <-- arch-autoupdate.xml new revision: 1.27; previous revision: 1.26 done Checking in autoupdate/libsrc/org/netbeans/updater/UpdateTracking.java; /cvs/autoupdate/libsrc/org/netbeans/updater/UpdateTracking.java,v <-- UpdateTracking.java new revision: 1.19; previous revision: 1.18 done Checking in autoupdate/nbproject/project.xml; /cvs/autoupdate/nbproject/project.xml,v <-- project.xml new revision: 1.14; previous revision: 1.13 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/AutoModuleNewType.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/AutoModuleNewType.java,v <-- AutoModuleNewType.java new revision: 1.10; previous revision: 1.9 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/Bundle.properties; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/Bundle.properties,v <-- Bundle.properties new revision: 1.155; previous revision: 1.154 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/ModuleCatalogAction.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/ModuleCatalogAction.java,v <-- ModuleCatalogAction.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/ModuleDeleter.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/ModuleDeleter.java,v <-- ModuleDeleter.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/ModuleDeleterImpl.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/ModuleDeleterImpl.java,v <-- ModuleDeleterImpl.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/Settings.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/Settings.java,v <-- Settings.java new revision: 1.32; previous revision: 1.31 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/UpdatePanel.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/UpdatePanel.java,v <-- UpdatePanel.java new revision: 1.108; previous revision: 1.107 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/Wizard.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/Wizard.java,v <-- Wizard.java new revision: 1.77; previous revision: 1.76 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/Bundle.properties; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/Bundle.properties,v <-- Bundle.properties new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleBean.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleBean.java,v <-- ModuleBean.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleEnableDisablePanel.form; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleEnableDisablePanel.form,v <-- ModuleEnableDisablePanel.form new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleEnableDisablePanel.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleEnableDisablePanel.java,v <-- ModuleEnableDisablePanel.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleNode.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleNode.java,v <-- ModuleNode.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleNodeActions.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleNodeActions.java,v <-- ModuleNodeActions.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleNodeUtils.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleNodeUtils.java,v <-- ModuleNodeUtils.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleSelectionPanel.form; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleSelectionPanel.form,v <-- ModuleSelectionPanel.form new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleSelectionPanel.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleSelectionPanel.java,v <-- ModuleSelectionPanel.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleUninstallPanel.form; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleUninstallPanel.form,v <-- ModuleUninstallPanel.form new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleUninstallPanel.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModuleUninstallPanel.java,v <-- ModuleUninstallPanel.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModulesAndDescription.form; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModulesAndDescription.form,v <-- ModulesAndDescription.form new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModulesAndDescription.java; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/catalog/ModulesAndDescription.java,v <-- ModulesAndDescription.java new revision: 1.2; previous revision: 1.1 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/resources/mf-layer.xml; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/resources/mf-layer.xml,v <-- mf-layer.xml new revision: 1.27; previous revision: 1.26 done RCS file: /cvs/autoupdate/src/org/netbeans/modules/autoupdate/resources/moduleCatalog.gif,v done Checking in autoupdate/src/org/netbeans/modules/autoupdate/resources/moduleCatalog.gif; /cvs/autoupdate/src/org/netbeans/modules/autoupdate/resources/moduleCatalog.gif,v <-- moduleCatalog.gif initial revision: 1.1 done Checking in ide/golden/cluster-deps.txt; /cvs/ide/golden/cluster-deps.txt,v <-- cluster-deps.txt new revision: 1.22; previous revision: 1.21 done Checking in ide/golden/deps.txt; /cvs/ide/golden/deps.txt,v <-- deps.txt new revision: 1.121; previous revision: 1.120 done Checking in ide/golden/external-libraries.txt; /cvs/ide/golden/external-libraries.txt,v <-- external-libraries.txt new revision: 1.4; previous revision: 1.3 done Checking in ide/golden/impl-deps.txt; /cvs/ide/golden/impl-deps.txt,v <-- impl-deps.txt new revision: 1.21; previous revision: 1.20 done Checking in ide/golden/modules.txt; /cvs/ide/golden/modules.txt,v <-- modules.txt new revision: 1.29; previous revision: 1.28 done Checking in ide/golden/shared-packages.txt; /cvs/ide/golden/shared-packages.txt,v <-- shared-packages.txt new revision: 1.4; previous revision: 1.3 done