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
