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 installing two modules, one of which depends on the other, via manually downloaded NBM files, sometimes it is successful, but sometimes I get: Warning: Could not install some modules: Simple MOF Notation - The module named org.brianlsmith.smn.mdr/1 was needed and not found I set this as high priority because this has direct user impact, potentially affecting even standard NetBeans modules available from autoupdate. Detailed Description: I have two modules, both of which are unsigned, and both of which have needsrestart=false. One is an autoload module "org.brianlsmith.smn.mdr/1." ("Simple MOF Notation Library") The other one is a regular module "org.brianlsmith.smn.netbeans/1" ("Simple MOF Notation"). "Simple MOF Notation" has a declared dependency on "Simple MOF Notation Library" which autoupdate obviously knows about (Because, if I choose "Simple MOF Notation", "Simple MOF Notation Library is automatically selected for me). What appears to be happening is this: Autoupdate writes the module XML file for org.brianlsmith.smn.netbeans/1. org.netbeans.core.modules notices that the module XML file was added and tries to install and enable org.brianlsmith.smn.netbeans/1. However, the enabling fails because org.brianlsmith.smn.mdr/1 hasn't beeing installed yet, and an error is displayed to the user. Then org.brianlsmith.smn.mdr/1 is installed. Now, if I enable org.brianlsmith.smn.netbeans/1 manually it gets enabled without any problem. Note that the problem doesn't happen every time. I think that if autoupdate writes org.brianlsmith.smn.mdr/1's module XML file first, then org.brianlsmith.smn.netbeans/1 gets installed correctly. But, the opposite way does not work. So, possible solutions seem to be: 1. For all regular (not autoload, not eager) modules, write the module XML file with "enabled=false". Then, go back after all the module manifests have been written and try to enable all those modules. 2. Write the module XML files in an order such that a module's XML file is never written before the XML file for a module it depends on. I worry that this is a very brittle solution because it depends on org.netbeans.core.modules to always install/enable modules in the order it received their "module XML file created" events. 3. Perhaps, org.netbeans.modules.core should not automatically enable modules when processing "module XML file created" events? If the core doesn't automatocally enable the module when its "module XML file created" event is received, then the files could be written exactly how they are now (i.e. enabled="true" in the XML), and then autoupdate would loop back through the modules and enable them manually via the API. This is the approach that I like, but I don't know what other parts of NetBeans besides autoupdate depend on the core automatocally enabling the module when the module's XML file is written. I have attached my ide.log, cut down to the the relavent messages. I set -Dorg.netbeans.core.modules=0 in ide.cfg to get this log, and I also added a lot message in NbEvents.java line 282 so I could see when/where the error was coming from.
Created attachment 7551 [details] ide.log with -J-Dorg.netbeans.core.modules=0
I vote for 2. option (installing in dependency order). Slightly decreasing the priority (because existing workaround), however I'll work on this issue the problem immediately.
Fixed in trunk. AU writes now Modules/*.xml files in proper order of dependency.
I don't think #2 is brittle. The module system will try to process file events as they come in; note that it can get a batch of them at once. If there are several new XML files all saying "enabled", AFAIK it will first create all the modules, then enable them all in order - at least ModuleList is written to work in this way. (The unit test does not yet cover this, however.) My *guess* is that this bug was caused by the filesystem actually delivering the creation event(s) for the dependent XML files before the event(s) for the base XML files, which of course cannot work. This seems to be supported by the log file, which delivers the second file change event after ML has already started processing the first. Perhaps AU creates each new XML file in its own FileSystem.AtomicAction - that will prevent ModuleList from knowing that all the modules should be installed "together".
This is not fixed completely yet. The problem is "better" now in that it doesn't happen nearly as often, but it still does occur. The times I have noticed it, it was my non-autoload module depending on my autoload module, with my non-autoload module not being able to start because it thought that the autoload module wouldn't start. I think I can produce a testcase for this that is more likely to show the problem, by creating a large number of "fake" modules with interdependcies that can then all be built into nbm's for testing. I will work on it in a few days...
I meant: "...with my non-autoload module not being able to start because it thought that the autoload module was not installed."
OK, probably I should create all XML files in one FileSystem.AtomicAction
Fixed in trunk. AU now creates all Modules/*.xml files in one FileSystem.AtomicAction
Thanks, I haven't noticed this problem at all in the last week. Probably the 3.4.1_CANDIDATE status of this bug should match issue 27600, especially since it is unlikely that somebody is going to install an autoload module without also installing a module that depends on it. I.e. either both should have it or neither should have it.
Brian, if you can confirm that the bug appears to be fixed in dev builds, please mark it VERIFIED. Did you see this bug in 3.4, or only in pre-4.0 dev builds? If you think it happens also in 3.4, please change the Version field to 3.4 and feel free to add the 3.4.1_CANDIDATE keyword to it. Thanks for detailed bug reports! Marking with THREAD keyword since the bug appears to involve a race condition.
verified