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. >
