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 36064 - Necessary to change the way friend modules can depend on each other via impl-version-number
Summary: Necessary to change the way friend modules can depend on each other via impl-...
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API
Depends on:
Blocks:
 
Reported: 2003-09-12 13:59 UTC by Antonin Nebuzelsky
Modified: 2008-12-23 08:32 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Proposed fix (minus @since 4.17 in getBuildVersion) (9.90 KB, patch)
2003-12-16 16:02 UTC, Jaroslav Tulach 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2003-09-12 13:59:50 UTC 
With the introduction of "friendship between
modules", the friend modules are supposed to be
referring each other via implementation version
number. (as stated in
http://openide.netbeans.org/unbranded-source/browse/~checkout~/openide/api/doc/org/openide/doc-files/classpath.html?rev=1.13.6.1&content-type=text/html):

> This manifest goes further and prevents any
packages from being
> available to other modules: 
> 
> Manifest-Version: 1.0
> OpenIDE-Module: org.netbeans.modules.a
> OpenIDE-Module-Public-Packages: -
>   
> You may still declare a dependency on such a
module, in order to
> ensure that it is installed (perhaps it provides
some non-Java-level
> service you need), but you may not import any
classes from it. 
> 
> There is a limited "back door" to this package
restriction: if module
> B declares that it knows about module A's
internal implementation, and
> is prepared to track arbitrary changes in A,
then it can use any
> public classes from A regardless of the public
package declaration.
> This is done using an implementation dependency: 
> 
> Manifest-Version: 1.0
> OpenIDE-Module: org.netbeans.modules.b
> OpenIDE-Module-Module-Dependencies:
org.netbeans.modules.a = 1.0-alpha-13jun03
  

Using implementation version number for this
purpose is unfortunate. I see two ways module
group owners can go in this case:

(1) web modules team is thinking about doing this
kind of dependency the way where implementation
version string continues to contain the build
number and thus only the modules in the group
which come from the same build will work together.

(2) xml modules team is using implementation
version string with static content (not containing
build number anymore, but rather a static string
which has to be modified manually each time a
module-group-private API changes).

From Sustaining point of view, none of these two
options is viable!

With the option (1), if we integrate one single
fix in one single module of a group, all modules
of the group coming from the same build must be
delivered to the user. With the option (2),
implementation version number no longer plays the
same role as it did until now. There would be no
way to tell the build number of modules. Which is
not acceptable for Support people.


From the discussions with Jesse and Yarda, the
following option came out, which has support from
also from me as well as from web module developers:

Continue using
OpenIDE-Module-Implementation-Version but use []
for distinguishing the part of it which should be
ignored for the dependency setting, thus having e.g.:

OpenIDE-Module: foo/1
OpenIDE-Module-Specification-Version: 1.3
OpenIDE-Module-Implementation-Version:
alpha-api-3[BLD030911]
...
OpenIDE-Module: deps.on.foo/1
OpenIDE-Module-Specification-Version: 1.0
OpenIDE-Module-Implementation-Version: BLD030912
OpenIDE-Module-Module-Dependencies: foo/1 =
alpha-api-3


Please, go on and implement this.
THX
Comment 1 Jaroslav Tulach 2003-09-12 14:50:00 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.
Comment 2 Antonin Nebuzelsky 2003-09-12 15:34:34 UTC 
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.
Comment 3 Jesse Glick 2003-09-12 15:42:28 UTC 
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.
Comment 4 Antonin Nebuzelsky 2003-09-15 09:33:38 UTC 
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?
Comment 5 Jesse Glick 2003-09-18 06:21:07 UTC 
Right, that's the idea.
Comment 6 Jaroslav Tulach 2003-12-16 16:02:49 UTC 
Created attachment 12605 [details]
Proposed fix (minus @since 4.17 in getBuildVersion)
Comment 7 Jaroslav Tulach 2003-12-16 16:03:56 UTC 
I will integrate it if two of you give me review.
Comment 8 Jesse Glick 2003-12-16 20:09:40 UTC 
Needed also for workspaceswitcher/navigator -> openide/looks.
Comment 9 Antonin Nebuzelsky 2003-12-17 13:59:14 UTC 
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]
Comment 10 Petr Jiricka 2003-12-18 08:28:05 UTC 
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
Comment 11 Jaroslav Tulach 2003-12-18 10:52:32 UTC 
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.
Comment 12 _ tboudreau 2003-12-18 12:22:06 UTC 
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.
Comment 13 Jaroslav Tulach 2003-12-18 13:52:42 UTC 
Enough of reviews. Let's integrate it.
Comment 14 Jesse Glick 2003-12-18 14:03:11 UTC 
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).
Comment 15 _ tboudreau 2003-12-18 14:52:54 UTC 
Once this is integrated, who will be responsible for updating Looks to
use the new dependency code?
Comment 16 Jaroslav Tulach 2003-12-18 15:26:41 UTC 
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
Comment 17 Jesse Glick 2003-12-18 18:08:59 UTC 
x
Comment 18 Jesse Glick 2003-12-18 18:09:20 UTC 
Resolution was missing for some reason.