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.
I.e. httpserver/manifest.mf: OpenIDE-Module-Provides: org.openide.util.HttpServer$Impl and e.g. web/core/manifest.mf: OpenIDE-Module-Requires: org.openide.util.HttpServer$Impl Then jsp.jar could only be enabled if httpserver.jar was too, yet there need be no direct dependency.
This could also be used for parts of core (e.g. org.openide.compiler.CompilationEngine provided by org.netbeans.core.compiler.CompilationEngineImpl) and XML (e.g. javax.xml.parsers.SAXParserFactory provided by org.apache.xerces.jaxp.SAXParserFactoryImpl).
Target milestone -> 3.4
*** Issue 17776 has been marked as a duplicate of this issue. ***
Probably important for various things.
Making a branch module_deps_jan_2002 in core + openide + apisupport to try to implement this, and maybe also bridge modules and cross-major-release dependencies.
Branching now nbbuild too. Bridge modules working.
Technical details: A module may specify an attribute OpenIDE-Module-Provides, with a list of one or more tokens, each of which is in the format of a valid code name base (identifiers separated by dots), separated by space and/or comma. It may also or instead have OpenIDE-Module-Requires in the same format. public String[] ModuleInfo.getProvides() will produce the provides list (maybe empty but never null). Dependency.TYPE_REQUIRES is added to represent dependencies of the requires type; such dependencies may have only a name, never a comparison. If A provides token X and B requires it, then B has an implicit dependency on A in the sense that A must be enabled for B to be enabled, and A must be enabled before B, and B must be disabled before A. B does *not* automatically get A as a parent in its classloader. Provide-require dependencies count as dependencies for purposes of cyclic dependencies, i.e. such cycles are illegal and will result in none of the affected modules being installable. If B requires X and no module provides it, B cannot be enabled. If B requires X and both A1 and A2 provide it, B can be enabled provided that at least one of A1 and A2 can be enabled. If A1 is enabled, whether or not A2 is, and a request is made to enable B, it is simply enabled. If neither A1 nor A2 is enabled, and a request is made to enable B, both A1 and A2 are also enabled if possible. If only one can, just that one is. If neither can, B cannot be enabled. If B requires X and both A1 and A2 provide it, and all are enabled, and a request is made to disable A1, it is simply done. If a request is made to disable both A1 and A2, B is also disabled. Little UI impact; same messaging used as for regular module dependencies. In case a module cannot be enabled because there are no enablable modules providing a token it requires, a different problem message is used than for a regular module dependency that failed.
Now apparently working correctly in the branch, pending unit tests.
Work complete in branch, pending merge. Also branched autoupdate to match.
Implemented. http://core.netbeans.org/source/browse/core/Attic/moddeps-todo.txt?rev=1.2&content-type=text/x-cvsweb-markup
verified in 3.4 dev builds