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:43:46 GMT
Do we really need this big change?

There are so many "duplicated" xml files whose original goal is to
achieve modularity.
So each component can be developed and tested separately.
I guess that's the reason that we got so many build scripts on each
modules of classlib.
(It is another story whether they worked as we expected)

I prefer to keep jdktools and classlib separately, it sounds more natural to me.

Best Regards
Sean, Xiao Xia Qiu




2009/7/23 Nathan Beyer <nbeyer@gmail.com>:
> 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