Best Regards Sean, Xiao Xia Qiu
2009/7/22 Mark Hindess <mark.hind...@googlemail.com>: > > 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 > 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? > >
