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:||Make it possible to restrict modules that depend on friend API|
|Product:||platform||Reporter:||Pavel Buzek <pbuzek>|
|Component:||Module System||Assignee:||Jaroslav Tulach <jtulach>|
|Severity:||blocker||CC:||apireviews, jglick, jtulach|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||59008|
|Attachments:||Introduction of OpenIDE-Module-Friends|
Description Pavel Buzek 2005-01-28 05:43:02 UTC
The premise of friend API is that the module owner who provides that API knows and is in contact in with the users of the API. http://openide.netbeans.org/tutorial/api-design.html#category-friend This is not enforced and defining public packages allows anybody use the API. This leads to a situation that this stability level is not used and developers create implementation dependencies (private API) which has many other disadvantages. The solution would be to add a manifest tag to list the modules that are in friend relationship with the provider of a friend API and only those modules would be able to use the API.
Comment 1 Pavel Buzek 2005-03-06 01:55:29 UTC
I got another idea how to simplify using friend API stability for module writters. By default, we could make the friend APIs visible to all modules in the same cluster. These are likely going to be maintained by the same developers so it should not hurt.
Comment 2 Jaroslav Tulach 2005-03-12 09:04:05 UTC
Created attachment 20797 [details] Introduction of OpenIDE-Module-Friends
Comment 3 Jaroslav Tulach 2005-03-12 09:08:04 UTC
Now we can have friend modules - e.g. restrict access to public packages just to pre enumerated list of modules. Documentation is missing, I know I should bump openide version, add api changes to openide/modules api and change documentation in openide/api/**/modules/** - if there is anything more to do let me know. If accepted, I'd like to integrate as soon as 4.1 is branched.
Comment 4 Jesse Glick 2005-03-14 14:39:17 UTC
+1 from me...
Comment 5 Jesse Glick 2005-03-14 19:20:23 UTC
Just realized a problem: you may want to make some packages in a module truly public, and others available only to friends. I think this is not uncommon at all. Suggest perhaps OpenIDE-Module-Public-Packages: org.netbeans.api.foo, org.netbeans.spi.foo, org.netbeans.modules.foo.spi[org.netbeans.modules.bar, org.netbeans.modules.baz] What do you think? Which reminds me - the manifest syntax is getting more and more complex, and it is painful to edit manifest files (especially since there are problems with trailing newlines, unexpected semantics for whitespace, weird line wrapping, etc.), and for "modularizing" 3rd-party libraries it is not so nice to have to edit the vendor's JAR manifest. Maybe we should switch to an XML manifest (META-INF/netbeans/module.xml?) which could use a more readable, schema-controlled syntax, clearly versionable and friendly to machine editing and XSLT processing... we could even embed the layer file (branding semantics TBD) to reduce the number of files and make it easier to see all the module config in one place. I think we could do something like this for F. Any interest? If so, I can file a separate RFE for that.
Comment 6 Jaroslav Tulach 2005-03-15 08:50:09 UTC
New format of module (dependencies) description is good, if nothing else we could get rid of the OpenIDE prefix. I'd like to ask for waiver on multiple types of public packages in one module. As you said, it would complicate the syntax and as far as I know we do not need that for the j2ee modules (which requested this feature). Moreover APIs with two different lifecycles would complicate the versioning. If I do incompatible change in friend API I should still increase the major version, shall I not? If I do that, I break the public api as well. So it might be better to just split the APIs into two modules. If that turns out to be strong restriction it can be addressed in the "xml rewrite" that is likely to be more expressive than this manifest version.
Comment 7 Jaroslav Tulach 2005-04-04 17:45:50 UTC
I'd like to integrate soon in the version shown in the diff.
Comment 8 Pavel Buzek 2005-04-04 18:49:53 UTC
+1 from me How about treating the modules from the same cluster as friends? Is there a reason why this is not desirable? One cluster usually meets the process requirements of friend API (developed by the same group of people, easy to upgrade to new versions, deployed as a single unit).
Comment 9 Jaroslav Tulach 2005-04-05 07:49:18 UTC
So +1 or -1? Just to remind, if nobody removes API_REVIEW_FAST, it will likely be implemented in its original state. The module system is cluster orthogonal, it does not provide any special treatment for them right now. So I preffer to not implement the suggestion to treat all modules in cluster as friends.
Comment 10 Pavel Buzek 2005-04-05 14:00:13 UTC
definitely +1 The requirement for cluster modules to be friend is a 'nice to have'. I just wanted to get your opinion (and reasoning). Thanks for that.
Comment 11 Jesse Glick 2005-04-06 19:00:29 UTC
I guess +1. It would be nice to be able to export both public and friend packages from one module, but perhaps splitting the module in half is wiser (though it could lead to module proliferation). The use case I have in mind, BTW, is for projectuiapi: it defines a public API/SPI, but also has a private SPI for projectui to implement; currently we use an impl dep for this.
Comment 12 Jaroslav Tulach 2005-04-11 13:02:29 UTC
cvs ci -m "#54123: Public packages can be restricted to only friend modules" Checking in openide/openide-spec-vers.properties; /cvs/openide/openide-spec-vers.properties,v <-- openide-spec-vers.properties new revision: 1.172; previous revision: 1.171 done Checking in openide/api/doc/changes/apichanges.xml; /cvs/openide/api/doc/changes/apichanges.xml,v <-- apichanges.xml new revision: 1.244; previous revision: 1.243 done 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.102; previous revision: 1.101 done Checking in core/src/org/netbeans/core/modules/Module.java; /cvs/core/src/org/netbeans/core/modules/Module.java,v <-- Module.java new revision: 1.56; previous revision: 1.55 done Checking in core/src/org/netbeans/core/modules/ModuleManager.java; /cvs/core/src/org/netbeans/core/modules/ModuleManager.java,v <-- ModuleManager.java new revision: 1.65; previous revision: 1.64 done 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.41; previous revision: 1.40 done Checking in core/test/unit/src/org/netbeans/core/modules/build.xml; /cvs/core/test/unit/src/org/netbeans/core/modules/build.xml,v <-- build.xml new revision: 1.25; previous revision: 1.24 done RCS file: /cvs/core/test/unit/src/org/netbeans/core/modules/jars/api-mod-export-friend.mf,v done Checking in core/test/unit/src/org/netbeans/core/modules/jars/api-mod-export-friend.mf; /cvs/core/test/unit/src/org/netbeans/core/modules/jars/api-mod-export-friend.mf,v <-- api-mod-export-friend.mf initial revision: 1.1 done RCS file: /cvs/core/test/unit/src/org/netbeans/core/modules/jars/uses-api-friend.mf,v done Checking in core/test/unit/src/org/netbeans/core/modules/jars/uses-api-friend.mf; /cvs/core/test/unit/src/org/netbeans/core/modules/jars/uses-api-friend.mf,v <-- uses-api-friend.mf initial revision: 1.1