harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Qiu <sean.xx....@gmail.com>
Subject Re: [general] jdktools and classlib?
Date Thu, 23 Jul 2009 08:45:33 GMT
Best Regards
Sean, Xiao Xia Qiu

2009/7/22 Mark Hindess <mark.hindess@googlemail.com>:
> In message <4A668437.3030401@gmail.com>, Regis writes:
>> Mark Hindess wrote:
>> >
>> > If you are reading the commits list, you will have noticed that I've
>> > been making a few improvements to the ant scripts in classlib.  I've
>> > still got a way to go before I've finished the refactoring but I've
>> > already started wondering about doing the same thing for jdktools.
>> >
>> > But the question that sprang to mind was why am I doing it twice.
>> > Why not just have the jdktools modules as modules in classlib?  You
>> > don't really lose anything in modularity since all classlib modules
>> > can be checked out alone and built against an hdk.
>> For me, this may be a bit confused - jdktools is not a part of
>> classlib. If I wanted to see code of jdwp, I would never thought it
>> was in classlib.
> But you would look for jre tools in the jdktools component?  I didn't
> really intend for this to be about the names since we've largely been
> happy to ignore the incorrect jdktools one for a long time.  Instead of
> 'classlib' just think of a name that means everything-except-the-vm and
> consider what I wrote again.  Does it make more sense now?
>> For Ant script, I'm not familiar with it, just flying thinking, is
>> it possible to extract common parts or make some templates to reduce
>> maintain efforts?
> There is already some sharing between components.  I'm increasing the
> use of common code in classlib at the module level at the moment.  We
> could do more sharing across components but refactoring these takes
> quite a bit of (elapsed) time[3].
> I guess I just don't understand why we don't just have two components:
> 1) VM (which can be replaced by another VM and was a modular structure
> to allow parts to be replaced, etc)
> 2) Everything else (which also has a modular structure that allows
> a downstream user to pick and choose the bits they need or wish to
> replace.
> -Mark.
>> > I think we'd gain in that jdktools might get a little more attention
>> > if it was built and tested with classlib[0].  (Currently it would
>> > break quite a few ports since samsa seems to have quite a few
>> > linux-isms.  I'll fix these shortly though.)
>> >
>> > Of course, it adds a little (20M on top of 250M) to the checkout
>> > footprint and the build/test takes a little longer so there is a
>> > downside.
>> >
>> > I've read the original thread[1] but I still don't see a good
>> > argument[2] for this separation.  What do other people think?
>> >
>> > Regards,
>> >  Mark.
>> >
>> > [0] and trunk -> branches/java6 merged with classlib
>> >
>> > [1] http://markmail.org/thread/l44kkyiom45ks6e6
>> >
>> > [2] That thread did contain an argument but not a good one and not one
>> >     related to this topic. ;-)
> [3] The changes are usually fairly straight-forward but testing each change
>    at federated-build, classlib, classlib-module, and hdk levels takes a
>    long time to run.  And there are lots of changes that could/should be
>    made.

Strongly agree with you.

Do we have any public testing server from Apache?
Can we run these tests with the Hudson Server of ASF?


View raw message