Problem Description
HowardLewisShip, Apr 26 2004, 1.0-alpha-4
In many cases, a particular module will include a number of services and configurations that are internal to that module. Whether for concerns about instability in an API, minimizing knowledge needed by users of a module, or some type of security concern, it makes sense that (sometimes) services and configuration points be visible only within a specific module.
Proposed Solution
Add a visibility attribute to <configuration-point> and <service-point>. It would default to public, but could be set to private.
There would need to be some number of API changes to faciliate this as well.
Discussion
At the risk of violating YAGNI, perhaps better scoping rules are needed. That is, something reminiscent of Java's protected modified, where a extension point would be visible within sub-modules. But what defines a sub-module? A module which has the current (exporting) module's id as a prefix?
KnutWannheden: The solution (it's really a workaround) to the corresponding problem in Ant (private targets) is to prefix the target name with a dash (e.g. <target name="-internal"/>). The target can't be invoked because the Ant command line frontend would parse it as an option (which doesn't exist). I suppose a pragmatic solution like this wouldn't work in HiveMind nor would it be desirable...
To minimize the knowledge needed by the user maybe a best practice would often suffice. The private and public parts could be split into two modules, as common in Java with .internal and .impl packages.