harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@4quarters.com>
Subject Re: Bootstrapping the classlibrary builds
Date Wed, 28 Dec 2005 15:34:09 GMT


Tim Ellison wrote:
> Geir Magnusson Jr wrote:
> 
>>Tim Ellison wrote:
>>
>>>Sure, if you don't want the runtime effects of OSGi then you have
>>>flexibility to package the classes into any shape, including an rt.jar.
>>> However, if we want to support runtime modularity including component
>>>versioning etc. then we will have to have a number of discrete bundles.
>>> If OSGi has the ability to put multiple bundles into a single JAR ...
>>
>>I thnk you are missing my point.  Sorry.  What I'm saying/asking is
>>about OSGi being one [of many possible] delivery "packagings" of the
>>class libraries.
> 
> 
> Can you think of any other runtime modularity systems that we should
> consider supporting?

Sadly "rt.jar" because I hope that other VMs will support our VM/lib 
interface, and thus our classlib, and manybe not yet do OSGi.

> 
> 
>>So yes, I think that we definitely want to do OSGi as our default
>>packaging for our full implementation of J2SE, but that doesn't seem to
>>have to dictate on how we work with the code as class library
>>developers, does it?
> 
> 
> Life is easier if we layout the source code in modules too (rather than,
> say, mash it all together and make the modularity a package-time event)
> because we can get development time support from OSGi-aware tools like
> PDE that will 'smack' you for references outside the module definitions,
> compilation against the target directory, etc.

What is "PDE"?

> 
> 
>>We have the circular dep issue to tangle with
>>(which seems to go away if we do a bootstrap uber-compile/uber-jar) and
>>we can also offer other packagings of the classlibrary to work with
>>systems that don't do OSGi support.
> 
> 
> Agreed.
> 
> 
>>And we don't know how 277 is going to turn out - we hope for OSGi-ish,
>>but one never knows...
> 
> 
> Makes it kinda difficult to support then ;-)  I say we cross that bridge
> when we get to it.

Right - the point is to not be exclusively OSGi based, because there are 
reasonable motivations for making a rt.jar possible...

geir

> 
> Regards,
> Tim
> 

Mime
View raw message