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...


> Regards,
> Tim

View raw message