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 the module is updated from autoupdate, it is stored into user_home/modules folder and ext libraries into user_home/modules/ext folder. But if there is some jar in modules/ext, IDE takes it from ide_home/modules/ext instead of user_home/modules/ext. Conclusion: it is not possible to update modules/ext libraries using autoupdate, because IDE still uses old ones.
Module system problem. Jesse could you please look at it? (The JarClassLoader doesn't look-up the extension itself and depends on the files provided by org.netbeans.core.modules.Module.classLoaderUp()
Updating from issue #15585, which started as purely java module - related problem: Additional Comments From Ivan Bradac 2001-09-18 06:13 PDT: There is a workaround: Restart Forte once again after the update. However, this workaround is unacceptable since updating via the autoupdate is a fundamental feature which must work correctly and if this functionality is broken, it leads to a NO-GO for any patch releases including the JP3.1. Therefore I have raised the priority. Reassigning to core since this is a general core problem. It occurs also for a lot of other modules and the possible problem could be in the ModuleInstaller which does not recognize new versions of modules located in the userdir. Raising priority accordingly (sustaining recommended P-1)
Just want to add that the behaviour (IDE does not recognize new versions of modules in user_dir\modules directory) does not apply to modules\ext only, but to all files in user_dir\modules directory.
But if you take a look at module's properties, it shows, that the module from user_dir is installed...
You're right, after discussion I take back what I previously said about whole user_dir\modules directory. There is probably another problem, which will be submitted as a separate bug.
Petr--this is in FFJ 3.0, your code is not involved... :-) I doubt this problem would occur in NB 3.3, the extensions are handled by Module which doesn't know anything about user dir or home dir. I assume that in the cases involved, the extension was updated as well? So you have $nbhome/modules/foo.jar (v. 1) $nbhome/modules/ext/foo-ext.jar (v. 1) $nbuser/modules/foo.jar (v. 2) $nbuser/modules/ext/foo-ext.jar (v. 2) In all cases the module should be loading the extension it is physically located next to, if not that is a serious bug... I will look into it. You say this only happens when the new module is first being installed, and not after IDE restart?
Jesse, it's good that you're looking at it. This is a high prio for us. Please also take care of #15599
I cannot reproduce this bug on a small test case. Unpack the attached ZIP; you will get two versions each (1.0 & 1.1) of two different modules (testmodule1 & testmodule2), each of which includes an extension (testext1 & testext2). Sources, build script, and final NBM included for all. Create a build of release32 (3.2.1) with just autoupdate module for testing with. Running in single-user mode, install 1.0 versions of testmodule1.nbm and testmodule2.nbm, so that these are modules are included in the "installation". Console prints messages saying that 1.0 version of code (in both modules, both from the module proper and from the extension) is in use. Now run in normal user mode with a fresh userdir. Install 1.1 versions of both NBMs. IDE restarts, and console says 1.1 version of code (in all four places) is in use, as expected. So #15586 I consider to be unreproducible. #15599 I will leave open on the suspicion that there is something broken in xml.nbm which is causing things to not work as expected. When I am able to get a copy of this new xml.nbm I can test against it. (I assume it is OK to start with pilsen EE FCS as of Aug 17? I have a copy of that locally.)
Created attachment 2599 [details] ZIP of test case modules
I've tested this testcase and it shows correct versions.
I assume this bug is really supposed to be a duplicate of #15599 or whatever (the P1 recently resolved), in which case the IDE knows that the user/modules/ext/ version is supposed to be used but in certain circumstances gets the classloader wrong anyway.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.