Currently, when you develop a module, the dependencies are set to whatever
version of NetBeans you're running against (unless you've already set up a
separate NB platform - most users won't have). If you then try to run such a
module in an earlier version, the only way to make it work is to manually
modify project.xml to back up the specification versions to whatever you're
It would be nice if you could specify a specific version of NetBeans to target
dependencies at - of course, verifying that the module will really run in that
version is another story (if we had really good use of @since tags,
conceivably it could be done but I'm not holding my breath).
What I'm envisioning is something like apisupport carting around a per-version
properties file, e.g.
etc. and some kind of radio button UI in the project properties to select.
May be complicated for cases like the openide split, but for the majority of
cases, should be pretty simple, and would remove an unnecessary pain-point in
module development that's probably pretty baffling for new users.
Simplest solution would be to change behavior of <parseprojectxml> slightly so
that if <specification-version> (and <release-version>) were missing from a
<run-dependency>, simply generate a dep on the version present in the actual JAR
you are building against. So then you could just switch platforms and do a clean
build to "backdate" your app. The GUI should then create <r-d> without <r-v> or
<s-v> in the Add Module Deps dialog, and could either not show spec versions at
all, or use a checkbox/radiobutton to let you either specify a particular dep or
to pick up the version from the platform.
1. For <implementation-version>, essentially this already happens.
2. I am considering making the build insert Java deps automatically, in issue
#70875, which would work much the same way.
Implication would be that you should always build against a version of the IDE
no newer than the oldest version you want to be able to run against. Could be
annoying in some cases, perhaps, but would also make sure that you are not
accidentally using newer APIs than you declare. We could use this for
netbeans.org modules, too - it would mean that to publish a new API you would
only need to update the spec version in the provider, not manually request it in
The downside is that if you are developing a module which you want to be able to
run in an older IDE, you would *have* to build it against that IDE - or manually
insert the right versions into project.xml. But perhaps this drawback is
balanced by the ease of the use of the proposed change.
(In the case of impl deps, it is I think always correct to add a dep on the
version in the JAR you are building against, so this behavior would not be changed.)
Notes from the list.
(o) Specification Dependency
This module will accept compatible upgrades of its dependency.
Only packages exported as public from the dependency may be used.
(o) Release and Specification Version from Current Dependency
( ) Manual Versioning (to accept older releases)
Major Release Version ≅ [1_____] (matches exact number or range, e.g. "2" or
Specification Version ≥ [6.6___] (matches this or any newer version)
( ) Implementation Dependency
Any Java package from the dependency may be used, at your own risk.
You must rebuild this module if its dependency is upgraded.
The implementation version will be taken from the current dependency.
Implementation Version = [20060103_____] (matches only this version)
Possible change in spec.version.base behavior (but might also be skipped):
1. Changing the way spec.version.base is used. Rather than appending each
automatic version number in turn (currently sorted) to the base to get the
actual spec version in MANIFEST.MF, add them up (plus 1, for technical reasons
of compatibility with the current scheme) and append the sum. So you would have
OIDE-M-Mod-Deps: A/2 > 2.0, C/1 > 1.0, ....
or something like this.
2. Removing the GUI control for "Append ... Automatically"; just do it quietly
under the appropriate conditions. (I.e.: when this module has an integer impl
version, or it has an impl dep on some module with an integer impl version, or
it has an automatic major release dep on some module.) When making some change
in versioning or module deps which would require spec.version.base, and
currently OIDE-M-S-V is hard-coded in manifest.mf, move it to spec.version.base
in project.properties; and (perhaps) vice-versa.
3. Treat a spec.version.base of x.y.0 as just "x.y" in the GUI, since people
usually forget to append the ".0" anyway. (The .0 is needed in case you want to
publish a branched release of this module, in which case it can be changed to
.1, .2, etc.) Display other spec.version.base values as is.
An issue is how to preserve compatibility with the 5.0 harness. We cannot simply
since the 5.0 harness will not accept it.
A somewhat hacky solution: produce
(that's Integer.MAX_VALUE; just 999 would probably work but this is complete)
and in the updated harness take the release version from the actual version. For
spec versions, use
and again in the updated harness take the spec version from the actual version
in such a case. This is OK with the old harness since x.y > 0 is equivalent to
x.y in OIDE-M-M-D.
The problem lies in modules with no major release version. I believe that
/0-2147483647 will *not* match them since their implied MRV is -1, and
is malformed syntactically and will be rejected. Possible workaround is to
or whatever the right number is at the time the dep is created, and replace it
anyway when you see
This would *usually* work even with the old harness, assuming that the dep
module did not undergo a MRV increment in the meantime, which is unusual.
*** Issue 128079 has been marked as a duplicate of this issue. ***
Perhaps it is unnecessary to maintain compatibility with older harnesses; the new harness could just automatically
insert current rel and/or spec versions when not specified in <run-dependency> (they are both optional).
*** Bug 201943 has been marked as a duplicate of this bug. ***
*** Bug 170114 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> Perhaps it is unnecessary to maintain compatibility with older harnesses; the
> new harness could just automatically
> insert current rel and/or spec versions when not specified in <run-dependency>
This would be the simplest approach, though the risk remains of accidentally building with an older harness. There are two cases to consider:
1. Your suite contains at least one module with a dependency on an API module which has a major release version. (This is the usual case, since many commonly used APIs like Options, Settings, and Projects specify major release versions.) In such a case an old harness would reject <run-dependency/> with a message like
Cannot compile against a module: .../platform/modules/org-netbeans-modules-settings.jar because of dependency: org.netbeans.modules.settings
which serves as a reminder to build the suite using a new harness.
2. Your suite contains no such module. Then an old harness will successfully build it, and the result will generally run fine, though ModuleAutoDeps might be triggered at compile and run time:
warning: had to upgrade dependencies for module m: added = [module org.openide.util.lookup > 8.0] removed = [module org.openide.util.lookup]; details: [#170056: Separate module for Lookup API]
WARNING [org.netbeans.core.modules]: had to upgrade dependencies for module m: added = [module org.openide.util.lookup > 8.0] removed = [module org.openide.util.lookup]; details: [#170056: Separate module for Lookup API]
The alternative would be to introduce http://www.netbeans.org/ns/nb-module-project/4 as a marker for modules using automatic versioning, though it is unclear what if any actual schema changes would be involved; NbmPackageStability  suggests that the whole <dependency> (inside <module-dependencies>) could be replaced with a simple <code-name-base> in most cases: <implementation-version> should no longer be necessary, <build-prerequisite/> and <compile-dependency/> generally co-occur, <compile-dependency/> without <run-dependency/> is quite rare, and <run-dependency/> without <compile-dependency/> (for runtime-only deps) is unnecessary if there is no penalty for including a JAR in your compile classpath so long as you do not actually use classes from it.
I am considering to add a property that would instruct the harness to always pick-up versions of modules one compiles against. No UI, just documented in README.
It would actually be pretty easy to set up a mapping of module versions to NetBeans releases - just
hg tags | grep ^release | sort
gives me a nice list of releases since 3.3. So, a script can run that, then iterate hg checkout for each tag, then some incantation of
find. -name manifest.mf
and parse each manifest file, and record a mapping of code-name-base : version info.
Write that out to disk and you've got your list mapping; with minimal cleverness it's easy to append on new releases.
just FYI, maven based platform development will always use the version that one compiles against. So the dependency spec version will always be equal to the spec version declared in the dependency's module jar file.
works more or less fine.