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 Tue, 27 Dec 2005 21:40:16 GMT


Tim Ellison wrote:
> Geir Magnusson Jr wrote:
> 
>>On Dec 25, 2005, at 5:13 PM, Tim Ellison wrote:
>>
>>>Stefano Mazzocchi wrote:
>>>
>>>
>>>>Maybe I'm missing something, but if A depends on B and B depends  on A,
>>>>isn't the separation between A and B something to reconsider?
>>>
>>>I agree that we should be minimizing these circular dependencies,  but if
>>>you make their avoidance a hard rule then you soon end up dragging  lots
>>>of code into a single massive-component.
>>
>>Is that really true?  The component can be a packaging artifact,  can't
>>it?  build a pile of class files in the easiest way possible,  and then
>>package as you need to...
> 
> 
> That's what I'm saying really.  So consider build-time and runtime
> separately.
> 
> At buildtime such cyclical dependencies likely mean that you want to
> build everything together so that all references can be resolved, and
> package them up into separate bundles (=JARs).  This means that the unit
> of compilation is a single massive component, and is the approach we
> have got at the moment in the classlib/trunk/make/build.xml.
> 
> We should aim to have the components separate at runtime (those
> different bundles) otherwise we would end up back at a monolithic
> rt.jar.  Now the rt.jar has some advantages, but if you want the runtime
> modularitity benefits of the OSGi framework then you have to go down the
> path of separate bundle JARs.  Minimizing the dependencies between the
> bundles will enhance the benefits of the bundle componentization.

No doubt - but this just is something we have to sell to people later on.

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

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

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?

geir


Mime
View raw message