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.

Bug 70917 - Automatic versioning of module dependencies
Summary: Automatic versioning of module dependencies
Status: NEW
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker with 2 votes (vote)
Assignee: pgebauer
Keywords: PLAN
: 128079 170114 201943 (view as bug list)
Depends on:
Blocks: 68633 198610 206885
  Show dependency tree
Reported: 2006-01-02 22:08 UTC by _ tboudreau
Modified: 2015-09-09 11:22 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2006-01-02 22:08:05 UTC
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 
building against.

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.
Comment 1 Jesse Glick 2006-01-02 22:44:44 UTC
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 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.)
Comment 2 Jesse Glick 2006-01-09 18:37:37 UTC
Notes from the list.

UI sketch:

(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, move it to spec.version.base
in; 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.
Comment 3 Jesse Glick 2006-01-12 00:26:41 UTC
An issue is how to preserve compatibility with the 5.0 harness. We cannot simply
use e.g.


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
generate a


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.
Comment 4 Jesse Glick 2008-02-22 00:42:05 UTC
*** Issue 128079 has been marked as a duplicate of this issue. ***
Comment 5 Jesse Glick 2008-09-15 13:31:47 UTC
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).
Comment 6 Jesse Glick 2011-10-12 22:08:46 UTC
*** Bug 201943 has been marked as a duplicate of this bug. ***
Comment 7 Jesse Glick 2011-12-12 23:03:18 UTC
*** Bug 170114 has been marked as a duplicate of this bug. ***
Comment 8 Jesse Glick 2012-02-08 05:08:19 UTC
(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 as a marker for modules using automatic versioning, though it is unclear what if any actual schema changes would be involved; NbmPackageStability [1] 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.

Comment 9 Jaroslav Tulach 2012-11-07 05:06:36 UTC
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.
Comment 10 _ tboudreau 2012-11-07 05:47:19 UTC
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 
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.
Comment 11 Milos Kleint 2013-01-15 13:44:50 UTC
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.