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 29577 - AU does not know about NbInstaller.refineDependencies
Summary: AU does not know about NbInstaller.refineDependencies
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: -S1S-
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
URL: http://www.netbeans.org/download/dev/...
Keywords:
Depends on: 30161
Blocks:
  Show dependency tree
 
Reported: 2002-12-16 17:06 UTC by Jesse Glick
Modified: 2004-03-15 15:22 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-12-16 17:06:12 UTC
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.
Comment 1 Jesse Glick 2002-12-16 17:14:41 UTC
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.
Comment 2 Jesse Glick 2002-12-26 21:47:22 UTC
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.
Comment 3 Jaromir Uhrik 2003-01-06 11:01:36 UTC
Version changed: 4.0dev -> S1S 4.2
Comment 4 Jesse Glick 2003-01-16 01:29:34 UTC
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.
Comment 5 Jesse Glick 2003-01-27 23:07:35 UTC
I might as well handle this, since I know how to do it pretty easily
now (I hope!).
Comment 6 Jesse Glick 2003-01-29 19:44:01 UTC
Patch appears to be working as expected.
Comment 7 Jesse Glick 2003-01-30 18:42:46 UTC
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
Comment 8 Marian Mirilovic 2004-03-15 15:22:52 UTC
verified