harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: xerces and xalan dependencies
Date Thu, 30 Apr 2009 16:26:08 GMT
On Thu, Apr 30, 2009 at 3:19 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Tony Wu wrote:
>> On Thu, Apr 30, 2009 at 3:19 PM, Mark Hindess
>> <mark.hindess@googlemail.com> wrote:
>>> In message <3b3f27c60904291750s2ac0530fib707c1c34e96400f@mail.gmail.com>,
>>> Nathan Beyer writes:
>>>> I've been thinking about how we consume Xerces and Xalan, especially
>>>> since we've had to do some of the more recent modifications to the
>>>> build scripts to manipulate the JARs and archives in various ways. As
>>>> an alternative to grabbing the binary packages, we could grab the
>>>> source code itself and do our own builds. We could do this by grabbing
>>>> the officially distributed source archives or we could checkout the
>>>> code directly via svn:externals pointing to release tags (some risk in
>>>> that).
>>> I'd rather not use svn:externals.
>> I dont like svn:externals either. Probably it's not necessary to keep
>> them up to date. How about vote for whether to update when discussing
>> the next milestone build. I incline to grab the src code so that we
>> won't heavily depends on the script.
> +1 to not using svn:externals.  It plays havoc with our version control!
>>>> One advantage this has is that the code would be compiled at the
>>>> bytecode level of our code (Xerces currently builds to support Java
>>>> 1.3). The other would be a more natural fit into the classlib module
>>>> structure, which would allow us to build and package manifests as well
>>>> as additional tests.
>>> I've been thinking about creating modules/xml (and modules/orb) so that
>>> these dependencies are handled in a way that is more consistent with
>>> our modular structure.  It would allow us to do things like
>>> -Dexclude.module=orb and not have to download the yoko dependency (which
>>> would be sensible for Harmony Select).
>> yes, I think it is the consistent with Nathan's "more natural fit into
>> the classlib module structure"
> yep
>>>> Just something I've been knocking around in my head. Any comments or
>>>> additional thoughts?
>>> We don't really do very much to the jar.  (Now that we are doing it only
>>> once per download rather than once per build) I don't think it is a big
>>> deal.  However, I like the idea of actually running xerces and xalan
>>> tests on Harmony and perhaps the best way to do that is to grab source -
>>> unless the tests are in a jar?
>> good point. we'd better run these tests on Harmony.
> All good points.  The only minor concern I have is that is we start to
> modify the dependencies (too much) we'll get into a world of hurt when
> trying to upgrade to the latest versions.
> Rather than locally customize a particular distribution there should be
> a point where we work closer with the dependency project to produce
> something more closely aligned to our use case.

Just to clarify one point - I am NOT talking about forking the code at
all. I was thinking more of a svn:externals, which I know people don't
like, a classlib-local type of "populate-src" or grabbing the source
archives, like we do for APR. I'm open to this type of dependency grab
for other Java dependencies too.

I've played in the Xerces code base from time to time and it's
extremely stable, but there are very few tests. I'm not as familiar
with the Xalan code base.


View raw message