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: | Automatic versioning of module dependencies | ||
---|---|---|---|
Product: | apisupport | Reporter: | _ tboudreau <tboudreau> |
Component: | Harness | Assignee: | pgebauer <pgebauer> |
Status: | NEW --- | ||
Severity: | blocker | CC: | jirka_x1, lebedkov |
Priority: | P2 | Keywords: | PLAN |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 68633, 198610, 206885 |
Description
_ tboudreau
2006-01-02 22:08:05 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. Background: 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 clients. 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. 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 "2-4") 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 simply OIDE-Mod: B OIDE-M-Spec-Vers: 1.0.0.13 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 use e.g. <specification-version/> since the 5.0 harness will not accept it. A somewhat hacky solution: produce <release-version>0-2147483647</release-version> (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 <specification-version>0</> 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 /-1-2147483647 is malformed syntactically and will be rejected. Possible workaround is to generate a <release-version>2</> or whatever the right number is at the time the dep is created, and replace it anyway when you see <specification-version>0</> 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 [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. [1] http://wiki.netbeans.org/NbmPackageStability 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. |