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: | Necessary to change the way friend modules can depend on each other via impl-version-number | ||
---|---|---|---|
Product: | platform | Reporter: | Antonin Nebuzelsky <anebuzelsky> |
Component: | Module System | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jglick, mentlicher, pjiricka, rkubacki, rnovak, sdedic, tboudreau |
Priority: | P2 | Keywords: | API |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | Proposed fix (minus @since 4.17 in getBuildVersion) |
Description
Antonin Nebuzelsky
2003-09-12 13:59:50 UTC
Instead of introducing FriendAPI (what is friend anyway?) tag I suggest to introduce OpenIDE-Module-Build-Number which would hold the build number of the module and would just be placed dumped into log. The rest of module system would remain unchanged and could use Implementation-Version for friend dependencies as in case of XML modules. Yardo, I think that Jesse's proposed method with a certain part of Impl-version string ignored for the dependency checking, is better than introducing a new OpenIDE-Module-Build-Number or OpenIDE-Module-FriendAPI-Version-Number. It solves both issues while using only OpenIDE-Module-Implementation-Version. Actually I like Yarda's suggestion a bit better since it should make the meaning of the manifest more apparent, and as he says not change the semantics of OIDE-M-I-V at all. Some day perhaps the manifest should be XML-ified; the format is getting complicated enough to cause problems, I think, and something validatable would be better. Fine. I don't have a problem with that either. So, OpenIDE-Module-Implementation-Version will contain a static text like alpha-api-3 and OpenIDE-Module-Build-Number will contain the dynamically created build number string. And the log at startup and module properties listed in the Options dialog will contain also OpenIDE-Module-Build-Number for each loaded module. Right? Right, that's the idea. Created attachment 12605 [details]
Proposed fix (minus @since 4.17 in getBuildVersion)
I will integrate it if two of you give me review. Needed also for workspaceswitcher/navigator -> openide/looks. The fix looks OK to me. Yet, one suggestion, could the console output produced by the method dumpModulesList() in NbEvents.java include both the build number and the implementation version number? Only if these two strings are different. For example in the format modulecodename [specvers implvers buildnum] and if the buildnum and implvers are equal the format would be modulecodename [specvers implvers] The change looks fine. I am wondering what are the followup tasks. I can think of the following: - change all module manifests to use the new tag (or should we only do this when modules actually need it?) - update documentation at http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/modules/doc-files/api.html I'll update the documentation (make it tcr ;-). No need to update all modules. Only those that are using special Impl version, as otherwise build number is taken from that. Any idea when this will be integrated? I'd like to put Navigator on alpha auto update, but this issue blocks it, because it won't run with a non-matching looks build. Enough of reviews. Let's integrate it. Comments on patch: 1. In the test, assertTrue("...", cyc2.gIV() != cyc2.gBV()); should be assertTrue("...", !cyc2.gIV().equals(cyc2.gBV())); 2. Wrong spec vers in apichanges.xml; should be 4.18? 3. core/manifest.mf should be a new version and dep on openide 4.18. And seconding: 4. modules/doc-files/api.html must be patched. 5. NbEvents should probably show both bV and iV if they differ. Modules which could use the new feature: tasklist APIs; XML "unstable" APIs such as code completion support (need semistable impl version for ant/grammar); Looks (need some impl version for listening to Look changes). Once this is integrated, who will be responsible for updating Looks to use the new dependency code? All comments should have been addressed in following commits: Checking in core/test/unit/src/org/netbeans/core/modules/ModuleManagerTest.java; /cvs/core/test/unit/src/org/netbeans/core/modules/ModuleManagerTest.java,v <-- ModuleManagerTest.java new revision: 1.31; previous revision: 1.30 done Processing log script arguments... More commits to come... Checking in core/test/unit/src/org/netbeans/core/modules/jars/cyclic-2.mf; /cvs/core/test/unit/src/org/netbeans/core/modules/jars/cyclic-2.mf,v <-- cyclic-2.mf new revision: 1.3; previous revision: 1.2 done Processing log script arguments... More commits to come... Checking in openide/openide-spec-vers.properties; /cvs/openide/openide-spec-vers.properties,v <-- openide-spec-vers.properties new revision: 1.126; previous revision: 1.125 done Processing log script arguments... More commits to come... Checking in openide/api/doc/changes/apichanges.xml; /cvs/openide/api/doc/changes/apichanges.xml,v <-- apichanges.xml new revision: 1.177; previous revision: 1.176 done Processing log script arguments... More commits to come... Checking in openide/api/doc/org/openide/modules/doc-files/api.html; /cvs/openide/api/doc/org/openide/modules/doc-files/api.html,v <-- api.html new revision: 1.92; previous revision: 1.91 done Processing log script arguments... More commits to come... Checking in openide/src/org/openide/modules/ModuleInfo.java; /cvs/openide/src/org/openide/modules/ModuleInfo.java,v <-- ModuleInfo.java new revision: 1.9; previous revision: 1.8 done x Resolution was missing for some reason. |