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.
When updates from UC are applied to core.startup or org.openide.filesystems modules, these modules are not updatable. Scenario 1: IDE installed by administrator, updates performed by administrator: everything is OK Scenario 2: IDE installed by administrator, updates performed by non-privileged user (who does not have write permissions for install dir): modules are stored in user dir, but after restart, old modules from install dir are loaded and new modules in user dir are ignored. Scenario 2 is common on Mac and Win Vista platforms. This problem does not allow us to update core modules (NB 6.1 patch 2 was delayed due to this issue). The problem should be solved for NB 6.5 or the problematic modules should be marked as non-updatable.
reassigning to Tonda to decide who will take care about it either module system or plugin manager
The launcher does not currently support loading such modules from the userdir. If there is no write permission to the platform cluster, AU should not permit these modules to be updated.
Could instead consider changing launcher behavior, e.g. for Unix: diff --git a/o.n.bootstrap/launcher/unix/nbexec b/o.n.bootstrap/launcher/unix/nbexec --- a/o.n.bootstrap/launcher/unix/nbexec +++ b/o.n.bootstrap/launcher/unix/nbexec @@ -403,6 +403,7 @@ cp="" updatercp="" + build_cp "${userdir}" build_cp "${plathome}" if [ -f "${userdir}/modules/ext/updater.jar" ] ; then However, that would only affect o.n.boostrap, openide.modules, and openide.util (i.e. lib/*.jar). For core.startup and openide.filesystems (core/*.jar), you would need to change o.n.MainImpl. Currently it _does_ add ${netbeans.user}/core/*.jar to CP, but after platform's version, so it cannot override those in platform. I'm not sure why this is so; perhaps Yarda can explain.
*** Issue 138999 has been marked as a duplicate of this issue. ***
Note for sustaining: this problem is WONTFIX for 6.1. You have to keep it in mind when producing 6.1 (or older) patches. For 6.5, we will resolve it. Most probably by changing launchers as Jesse suggests above.
Confirmed this bug in NB6.1 FCS. I'm going to fix it for NB6.5
IMHO it's not a bug in Autoupdate code but problem in bootstrap module. Autoupdate correctly install updates into userdir iff install dir is read-only but updates won't be on classpath. I can confirm Jesse's proposed patch will work with o.n.bootstrap, openide.modules and openide.util and not for core.startup and openide.filesystems. I could propose a patch for ModeImpl which makes these module upgradeable as well but it's workaround rather then bugfix. Anyway, the attached patch can solve the reported problem.
Created attachment 65403 [details] possible patch
Just a note: NetBeans cannot update modules like boot.jar or core.jar in this case of real-only install dirs in ever releases before (3.x, 4.x or 5.x), it just disallows users to do that. Users have to make the install dirs read/write and then try it again. It could be the fallback if we won't find the correct fix in MainImpl.
Your patch looks OK except that BootClassLoader.run already appends ${netbeans.user}/core/*.jar, called as the runWhenHome param of CLIHandler.initialize, so this would cause such JARs to be added twice to the loader's CP unless you also change BCL.run to not append those JARs. The convoluted logic is I guess because only CLIOptions (in core.startup) actually sets netbeans.user from --userdir, but perhaps Yarda can confirm. Note that CLIOptions also calls FileUtil.normalizeFile on the userdir, which is not possible from MainImpl since it cannot access FileUtil; not sure if this could be important.
fixed: rev/dca1ee0c1f6d nbexec and o.n.boostrap code were fixed. patched nbexec.exe is coming soon.
windows part: 876e6604cf04
The problem still remains when updating org-openide-filesystems. I'm investigating...
FYI: Some problems still remains in nbexec. 1) build_cp "${userdir}" is not called after updater run 2) application cp can contain a few times boot.jar Need to more fixed in nbexec to avoid these problems.
I'll attach diff of nbexec which solves problem I stated before. Jesse, please review. The matter of the patch is, construct application classpath again after updater ran and cares to don't add jar twice in the classpath. Thanks
Created attachment 68025 [details] proposed nbexec patch
[ -z `echo ${paths} | grep ${subpath}` ] should probably be replaced with echo "$paths" | fgrep -q -v "$subpath" Get rid of echo "*** Added $x"
Jesse, thanks for review. I'll follow your suggestions and integrated the patch ASAP.
fixed in nbexec: ab5db07a97bd Need to fix in windows part also
Integrated into 'main-golden', available in build *200808280201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/ab5db07a97bd User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: #139051: Some of core modules are not updatable
Windows launcher part in 14b440a5f2cc
Integrated into 'main-golden', will be available in build *200809050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/14b440a5f2cc User: Tomas Holy <t_h@netbeans.org> Log: #139051: Some of core modules are not updatable (Windows part in launcher)
Build: NetBeans IDE Dev (Build 200809071401) VM: Java HotSpot(TM) Client VM, 1.6.0_02-b06, Java(TM) SE Runtime Environment, 1.6.0_02-b06 OS: Windows Vista, 6.0, x86 User Comments: Stacktrace: java.lang.NoClassDefFoundError: org/netbeans/updater/XMLUtil
Created attachment 69402 [details] stacktrace