harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Class library componentization
Date Mon, 25 Jul 2005 15:27:19 GMT
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message