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.

Bug 20323 - Allow Uninstall Module
Summary: Allow Uninstall Module
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker with 3 votes (vote)
Assignee: Jiri Rechtacek
URL:
Keywords: UI
: 19346 26299 41482 45903 (view as bug list)
Depends on: 21114 54668 55475 58663 61028
Blocks: 27296
  Show dependency tree
 
Reported: 2002-02-08 10:10 UTC by akemr
Modified: 2005-09-05 09:52 UTC (History)
9 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
1st draft of uninstall implementation (7.65 KB, patch)
2005-05-06 19:22 UTC, Jiri Rechtacek
Details | Diff
2nd prototype (12.37 KB, patch)
2005-05-13 17:36 UTC, Jiri Rechtacek
Details | Diff
3rd draft (43.57 KB, patch)
2005-05-25 15:52 UTC, Jiri Rechtacek
Details | Diff
merge candidate (w/o UI support) (45.90 KB, patch)
2005-05-26 20:08 UTC, Jiri Rechtacek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description akemr 2002-02-08 10:10:21 UTC
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.
Comment 1 akemr 2002-02-08 10:18:30 UTC
keyword UI added
Comment 2 akemr 2002-02-08 10:54:02 UTC
*** Issue 19346 has been marked as a duplicate of this issue. ***
Comment 3 Jesse Glick 2002-02-08 12:10:34 UTC
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.
Comment 4 akemr 2002-02-08 12:39:45 UTC
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
Comment 5 Jesse Glick 2002-02-08 13:31:43 UTC
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.
Comment 6 akemr 2002-02-27 16:04:30 UTC
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
Comment 7 Jesse Glick 2002-02-28 11:25:51 UTC
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).
Comment 8 Jesse Glick 2002-02-28 11:26:24 UTC
Forgot: use

-J-Dorg.netbeans.core.modules=0

to get the interesting messages in the log file.
Comment 9 Jesse Glick 2002-03-01 10:12:57 UTC
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"
Comment 10 akemr 2002-03-04 09:05:41 UTC
I created issue #21114 for Jesse
Comment 11 _ ttran 2002-03-15 08:54:00 UTC
desirable request, but we may not have enough resource to work on it
for 3.4.  Lowered prio to P3
Comment 12 Marek Grummich 2002-07-22 08:26:31 UTC
Target milestone was changed from '3.4' to TBD.
Comment 13 Jesse Glick 2002-08-06 14:51:23 UTC
*** Issue 26299 has been marked as a duplicate of this issue. ***
Comment 14 Marian Mirilovic 2002-12-06 18:50:41 UTC
reassigne to Hrebejk, new owner of autupdate 
Comment 15 Jesse Glick 2002-12-09 18:27:04 UTC
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.
Comment 16 iformanek 2003-01-27 17:06:08 UTC
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.
Comment 17 Jesse Glick 2003-02-11 18:45:05 UTC
Suggest this be scheduled for 3.5.
Comment 18 Marian Mirilovic 2003-12-01 10:49:10 UTC
reassigne to Jirka - new owner of autoupdate
Comment 19 Jesse Glick 2004-03-31 19:51:23 UTC
Clearly this did not make it for 3.6. :-(
Comment 20 Jesse Glick 2004-03-31 19:51:48 UTC
*** Issue 41482 has been marked as a duplicate of this issue. ***
Comment 21 Jesse Glick 2004-07-07 22:39:49 UTC
Nor for promo-D.
Comment 22 Jesse Glick 2004-07-07 22:40:03 UTC
*** Issue 45903 has been marked as a duplicate of this issue. ***
Comment 23 Jesse Glick 2004-07-07 22:42:00 UTC
Trung, please consider this seriously for E.
Comment 24 johnmuir 2004-08-26 06:25:55 UTC
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!
Comment 25 Jesse Glick 2004-08-27 03:49:18 UTC
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.
Comment 26 Jiri Rechtacek 2004-12-08 10:02:24 UTC
*** Issue 27296 has been marked as a duplicate of this issue. ***
Comment 27 iformanek 2005-02-16 14:45:37 UTC
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.
Comment 28 _ mihmax 2005-02-16 15:30:42 UTC
Hi Ian,
I beleive you should become a NetCAT participant, IssueZilla simply
doesn't work in netbeans.org project, imho.
Comment 29 Jiri Rechtacek 2005-02-28 13:22:18 UTC
This task has been added to NetBeans Feature Plans for promoF.


Comment 30 chrisnielsen 2005-03-06 18:02:09 UTC
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!
Comment 31 Jiri Rechtacek 2005-05-06 19:22:30 UTC
Created attachment 22010 [details]
1st draft of uninstall implementation
Comment 32 Jiri Rechtacek 2005-05-06 19:28:13 UTC
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.
Comment 33 Jesse Glick 2005-05-06 20:43:02 UTC
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.
Comment 34 Jesse Glick 2005-05-06 21:02:26 UTC
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.
Comment 35 Jiri Rechtacek 2005-05-10 16:41:02 UTC
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.
Comment 36 Jesse Glick 2005-05-10 17:01:37 UTC
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.
Comment 37 Jiri Rechtacek 2005-05-13 17:36:54 UTC
Created attachment 22128 [details]
2nd prototype
Comment 38 Jiri Rechtacek 2005-05-13 17:41:50 UTC
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.
Comment 39 Jesse Glick 2005-05-14 22:17:23 UTC
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.
Comment 40 Jiri Rechtacek 2005-05-16 13:26:20 UTC
> (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.

Comment 41 Jesse Glick 2005-05-16 17:40:39 UTC
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.
Comment 42 _ mihmax 2005-05-16 17:50:48 UTC
> (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.
Comment 43 Jan Chalupa 2005-05-16 17:52:52 UTC
> 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.
Comment 44 Jiri Rechtacek 2005-05-17 16:29:48 UTC
> 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.
Comment 45 Jesse Glick 2005-05-17 18:37:19 UTC
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.
Comment 46 Jiri Rechtacek 2005-05-25 15:52:13 UTC
Created attachment 22303 [details]
3rd draft
Comment 47 Jiri Rechtacek 2005-05-25 16:04:25 UTC
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
Comment 48 Jiri Rechtacek 2005-05-26 20:08:01 UTC
Created attachment 22328 [details]
merge candidate (w/o UI support)
Comment 49 Jaromir Uhrik 2005-06-16 09:09:54 UTC
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".
Comment 50 Jesse Glick 2005-06-21 17:57:32 UTC
juhrik's #2, #3, and #4 are probably RFEs that should not block implementation
of this feature.
Comment 51 Jaromir Uhrik 2005-06-22 08:57:08 UTC
OK, I have filed enhancements #60367, #60368, #60369 for these features.
Comment 52 Jiri Rechtacek 2005-07-12 15:57:55 UTC
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
Comment 53 Jesse Glick 2005-07-12 23:06:03 UTC
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.
Comment 54 Jiri Rechtacek 2005-08-03 15:04:50 UTC
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