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.
There is a bit of a problem with AU and finding proper module dependencies. The trouble is that NbInstaller.refineDependencies is called by the module system when loading a module. This can add or modify the effective module dependencies from those listed in the manifest. The purpose is to enable the system to gracefully upgrade old modules to work with newly divided APIs and similar things. One common example is that pre-3.14 modules get automatic deps on org.openide.deprecated and org.openide.src, and pre-3.17 modules get deps on org.openide.compiler, org.openide.execution, and org.openide.io. (Also corresponding require-tokens like org.openide.TopManager, etc.) Now take a dev build of the platform and run AU. Select Makefiles (org.netbeans.modules.makefile), v 1.4. Nothing else is selected for you, yet if you download & install it, after restart it will not be enabled, since it is missing its dependencies: org.openide.execution etc., which are not in the default platform config. Not sure what the best solution is. Copying and pasting code from NbInstaller, and maintaining two copies, is not an attractive prospect. But there is no API to access this information currently - ModuleInfo.getDependencies will give the refined dependencies for an *existing* real module (based on a JAR etc.), but if you just make a dummy ModuleInfo as AU does, this will not work.
Note: in fact this applies to a lot of maintained modules, even. For example, org.netbeans.modules.java now declares its real dependencies (e.g. org.openide.compiler). However, it is still at the same version (1.13) as it was before the 2nd API split. So the version in AU is the pre-split manifest, and selecting this module does not prompt you for org.openide.compiler etc. Workaround would of course be to go through all dev modules that were affected by the split and make sure they get spec version increases. Then only unmaintained modules would be problematic. Marking P2 because this applies to so many maintained modules that people would commonly want to download into the platform: editor, etc. Comes up a lot on mailing lists; people try to use the dev platform and add the editor from AU, and it does not work, and there is no apparent reason why.
Symptoms for dev platform users: After building dev platform and asking Dev AU for typical modules, the NBMs are downloaded but fail to install, citing many missing dep messages such as Compiler API. Workaround: From the NB Update Center Alpha, under Night Build Modules, get Deprecated APIs, Deprecated Core, Java Source Model, Execution API, Compiler API, Core - Compiler, and Core - Execution.
Version changed: 4.0dev -> S1S 4.2
Fix for issue #30161 should make this implementable in AU. Will supply a publically accessible method that AU can call to mimic the effect of refineDependencies.
I might as well handle this, since I know how to do it pretty easily now (I hope!).
Patch appears to be working as expected.
committed * Up-To-Date 1.39 autoupdate/build.xml committed * Up-To-Date 1.47 autoupdate/manifest.mf committed * Up-To-Date 1.8 autoupdate/src/org/netbeans/modules/autoupdate/DummyModuleInfo.java
verified