and e.g. web/core/manifest.mf:
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
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
Branching now nbbuild too. Bridge modules working.
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
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.
verified in 3.4 dev builds