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 <nbe...@gmail.com>: > On Wed, Jul 22, 2009 at 3:01 AM, Regis<xu.re...@gmail.com> wrote: >> Mark Hindess wrote: >>> >>> In message <4a668437.3030...@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. >> >
