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.
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.
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.
Created attachment 20797 [details]
Introduction of OpenIDE-Module-Friends
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.
+1 from me...
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,
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.
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
I'd like to integrate soon in the version shown in the diff.
+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).
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.
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.
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.
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
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
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
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
Checking in core/src/org/netbeans/core/modules/ModuleManager.java;
new revision: 1.65; previous revision: 1.64
new revision: 1.41; previous revision: 1.40
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
initial revision: 1.1
initial revision: 1.1