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 14:43:24 GMT


Tim Ellison wrote:
> Geir Magnusson Jr wrote:
> 
>>>p.s.  It is too bad that the OSGi bundles are so closely tied to the
>>>physical packaging of the code in JAR files -- but I don't see that
>>>changing anytime soon.
>>
>>That doesn't really matter to us, though, does it?  Because it's a
>>packaging issue, out of the soup of compiled classes, we can produce a
>>build target that assembles the OSGi bundles.  At the same time, we can
>>offer build targets that assemble into other things that people may want
>>(like an monolithic rt.jar).
> 
> 
> 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.

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

And we don't know how 277 is going to turn out - we hope for OSGi-ish, 
but one never knows...


> 
> 
>>So - does this mean we can reconsider our current organization strategy
>>of modules in the classlib part of Harmony?  IOW, does it continue to
>>make sense to separate them?  I think that the answer is still yes (with
>>some reorg like we were talking about last week)...
> 
> 
> I think the answer is still 'yes' as well -- it gives us the flexibility
> to package either way quite easily.  IIRC the reorg is a minor directory
> rearrangement to make it look like the Maven2 standard directory layout,
> agreed?

I defere to you on this - you know what's needed to actually build what 
we have at the moment. Does the maven2 standard layout work?  what about 
our multiple parallel native directories and tests?  (I need to go look 
back at the layout thread...)

> 
> 
>>Maybe the solution is to have a two-phase bootstrap compilation process.
>> Have a target that effectively makes rt.jar to avoid the cyclics, and
>>then use that rt.jar to make the modules.  Once you have the modules, I
>>assume we can discard the rt.jar thingy.  Unless we modify two at the
>>same time, in which case it's an easy fallback to the meta compile?
> 
> 
> Yes, we agree on the idea of a one-time 'bootstrap' build, which enables
> subsequent 'component' builds against the target.
> 
> The bootstrap build can be either a monolith rt.jar, or a script like
> the current global build.xml that packages into the component bundles
> (by reference to a number of patternsets).  The advantage of creating
> bundles from the start is that subsequent component builds don't have to
> differentiate between building against an rt.jar or against existing
> bundles.

That works.  I don't really care about having an rt.jar - that was just 
a mental device for me to explain what I was thinking.  Then the 
circular deps issue goes away?

> 
> The bootstrap build would also require an existing 'javac'
> implementation, whereas subsequent component builds could be
> self-hosting using the Eclipse batch compiler [1]

Cool.  I realize I don't know enough about the Eclipse compiler.  I 
didn't realize it could do partial builds.. :)

> 
> [1]
> http://help.eclipse.org/help31/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm
> 
> Regards,
> Tim
> 

Mime
View raw message