Bug 54123 - Make it possible to restrict modules that depend on friend API
Make it possible to restrict modules that depend on friend API
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Module System
4.x
All All
: P1 (vote)
: 5.x
Assigned To: Jaroslav Tulach
issues@platform
: API, API_REVIEW_FAST
Depends on: 59008
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-28 05:43 UTC by Pavel Buzek
Modified: 2008-12-22 20:54 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Introduction of OpenIDE-Module-Friends (9.87 KB, patch)
2005-03-12 09:04 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 
 


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo