A mashup that creates "jdklibs" ... I know I don't pay much attention to the jdktools portion, so that does seem like a strong point.
On Tue, Jul 21, 2009 at 9:55 AM, Mark Hindess<mark.hind...@googlemail.com> 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. > > 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. ;-) > > >
