harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <nbe...@gmail.com>
Subject Re: [general] jdktools and classlib?
Date Thu, 23 Jul 2009 03:00:24 GMT
On Wed, Jul 22, 2009 at 3:01 AM, Regis<xu.regis@gmail.com> wrote:
> Mark Hindess wrote:
>>
>> 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
>
> I guess so, since JDK includes a JRE, it makes sense for me.
>
>> 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?
>
> I agree that move them together make things easier, but still not sure
> 'classlib' is right place to put all them in. I can think 'classlib' means
> 'everything-except-the-vm', but not everyone can, especially ones just join
> the community.

Then we change the name to have it make more sense.

-Nathan

>
>>
>>> 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.
>>
>>
>>
>
>
> --
> Best Regards,
> Regis.
>

Mime
View raw message