Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor
 denied by domain of t.p.ellison@gmail.com)
Message-ID: <43B29FC3.3070108@gmail.com>
Date: Wed, 28 Dec 2005 14:22:59 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Bootstrapping the classlibrary builds
References: <43ABF70E.9040702@gmail.com> <43ACF80F.1080805@apache.org>
 <43AF19A1.5050101@gmail.com>
 <9DDE9268-562C-4C1D-8842-62A4BD2E33E3@4quarters.com>
 <43B1A564.3060608@gmail.com> <43B1B4C0.3080208@4quarters.com>
In-Reply-To: <43B1B4C0.3080208@4quarters.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

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

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

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

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

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.