Bug 19714

Sometimes it happens that a library module A/1 1.1 has two subcomponents
(packages say), Ax and Ay, but they are together in one module. Module B depends
on A/1 > 1.1 and uses Ax, but does not care about Ay. Now it is decided to
refactor Ay into an incompatible and different Ay2, so A/2 2.0 is released with
Ax and Ay2. Technically A is now incompatible, hence to move to the A/2 major
release. However module B needs to change its declaration to A/2 > 2.0 even
though it is not affected by the change at all and could work just as well with A/1.

So feature: permit B to declare in its manifest:

OpenIDE-Module-Module-Dependencies: A/1-2 > 1.1

(syntax look natural?)

which will be satisfied by module A if either:

1. It is major version 1, and the spec vers is >= 1.1.

2. It is major version 2 or higher (any spec vers).

Usage style: B would initially have the normal dependency on A/1 > 1.1. When A
is refactored into A/2 2.0, and the developer of B examines the changes and is
satisfied that the refactoring did not incompatibly affect the portion B uses
(Ax), the developer of B may change its dependency to A/1-2 > 1.1 and release a
new version of B with this dependency update. This ensures that the same version
of B will work with appropriate existing versions of A/1, as well as with any
version of A/2 (it must be kept compatible after 2.0 of course, so this is
known). It is possible that a further future refactoring into A/3 could break
the Ax package, so the dependency does not make any claims about B's
compatibility or incompatibility with the hypothetical A/3.

Generally then a module dependency may be of the newly added forms

X/j-k

or

X/j-k > m.n.o

(no implementation version comparison permitted in this style!)

Where X is a valid module code name base; j and k are integers, 0 <= j < k;
m.n.o is a valid specification version.

The first matches any version of X whose major release version is between j
(inclusive) and k (inclusive). The second matches any version of X whose major
release version is j and whose specification version is greater than or equal to
m.n.o; as well as any version whose major release version is between j
(exclusive) and k (inclusive), whatever the specification version.

Conventionally, to minimize confusion, specification versions should always go
up and not down when raising the major release version, but technically a higher
major release version always indicates a newer module, regardless of the
specification version.

Impact on APIs other than permitting the new kind of dependency: minor
implementation change in org.openide.modules.Dependency parsing code.