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.
Summary: | Implement provides-requires semantics for module dependencies | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Module System | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | issues, rkubacki |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 17501 | ||
Bug Blocks: | 17773, 17815, 23399 |
Description
Jesse Glick
2001-12-18 15:08:06 UTC
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 Target milestone -> 3.4 Target milestone -> 3.4 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 |