Richard S. Hall wrote: > Geir Magnusson Jr. wrote: > >> I assume that what we really need is two kinds of component export, >> the public app level API (java.util.*) and a public-yet-not-for-app- >> but-fellow-traveler API, such as what other conspiring modules would >> export to each other to provide the full public API. >> >> Kinda like "friend API" w/o the horror of having to declare who your >> friends are... > > > > You can achieve this sort of effect with some of the new constructs > proposed for OSGi R4, since you can include/exclude classes from > exported packages
So in OSGi R4 you can export/import individual classes as well as entire packages? > and then use mandatory attributes to restrict > visibility. It is probably not the cleanest way of doing this, but it > does work. What do you mean by 'mandatory attributes'? Is this a conditional export/import? >> Sure - Can we also version the supported public-for-friend API in >> some way? (I need to go read the OSGi spec...) > > > > No, there is only one package version. So, if they have the same package > name, then they can only have one version. If you want multiple > versions, then you have to have multiple separate packages. There are > some ways to cheat on this perhaps, since a package can be exported > multiple times, but it would be ugly. I don't think we need this. The internal (implementation) API need not be in a public API package, so just export the org.apache.<whatever> package with restricted visibility. > Perhaps what OSGi needs is general version attribute support, so that > people can attach arbitrary version attributes for this type of thing. > Or better yet, a general dependency model. All of this, however, would > start to greatly complicate the framework implementation. > > -> richard > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
