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?


View raw message