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 213996 - Create separate "extra" cluster distinct from userdir
Summary: Create separate "extra" cluster distinct from userdir
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Libor Fischmeistr
Depends on:
Reported: 2012-06-11 15:38 UTC by Jesse Glick
Modified: 2014-02-10 14:15 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-06-11 15:38:50 UTC
Traditionally Auto Update installs modules with no specified target cluster directly into $userdir/ as if this were a cluster, thus creating e.g.


The problem is that this mixes module installations into per-user configuration. In particular, $userdir/config/ is normally reserved for _overrides_ of module installed defaults, and other files which are created by user actions. When these are mixed with unpacked NBM contents, there is no good way to see what has been overridden, or to revert those modifications (e.g. config/Modules/*.xml#enabled) except by uninstalling and reinstalling the module.

Better would be to define an always-writable pseudocluster $userdir/extra/ into which NBMs could be installed, and add that to ${netbeans.dirs} in the launcher. Then it is clear that $userdir/extra/ contains nothing but pristine unpacked NBMs, and the rest of $userdir/ is user customizations and data.

For compatibility with old userdirs, AU when preparing for an update could look for $userdir/update_tracking/*.xml. If any exist, check their last-installed CRCs. If the corresponding files all exist in $userdir/, and match the installed CRCs, then move the tracking file and the installed files to $userdir/extra/. For modules listed in $userdir/update_tracking/*.xml which seem to be "dirty" (e.g. $userdir/config/Modules.*.xml has been modified since installation), leave them where they are unless and until that module is marked for an update.