Hi, [Per/Julian could you take a look at this and give your opinion on gnu bytecode/gjdoc?]
On Wed, 2006-03-29 at 12:20 -0700, Tom Tromey wrote: > I think moving stuff to a separate module was probably a mistake, in > retrospect. I'd like to propose moving the remaining tools back into > classpath, this time into the tools/ directory, which IMO is working > well for us. > > Ideally we would also move gjdoc as well. > > Comments? Objections? The idea behind having separate modules for the GNU Classpath core classes and the GNU Classpath Tools was that it would enable separate releases/bug-fixes for the tools without tying them to the core class release schedule. This has worked somewhat for the gjdoc, but clearly failed for all other tools. All GNU Classpath developers do have access to the cp-tools and gjdoc modules, but very few actually take advantage of it. So for nativetoascii, javah, javap, serialver and the rmic tools it seems a very good idea to do this. Likewise for the new jarsigner tool already moved into the main classpath module (and maybe a new jar tool?). For gjdoc I think we should leave it up to Julian who has a pretty good track record supporting the tool in a separate module. The other advantage of having GNU Classpath Tools (cp-tools) "separate" was that it was clear what are standalone tools and tools which are specific to GNU Classpath (core classes). But that doesn't really go up anymore since cp-tools also contains currencygen, ldml and localegen. Those are actually really needed if you want to "bootstrap" classpath core libraries completely from scratch so it does also make sense to include those in the main repository module. But it would be nice to have a separation between "internal" and "external" tools. Also at least the new jarsigner tool is not completely independent from the core classes. I don't know if this can be "fixed", or whether it should be. The only real concern I have is that this pulls in extra external dependencies. gjdoc pulls in antlr as parser generator and we already use jay (for the XPathParser) in the core classes. And cp-tools pulls in both asm and gnu.bytecode as byte code generator frameworks. And it seems we need very specific/altered versions of both (!). But I see Archit just posted a patch to the cp-tools mailing list to upgrade the dependency of ASM to 2.0 (but 3.0 is around the corner). I would very much like to see us depend on only one framework for both parser generators and byte code generators. And preferably track "upstream" versions. Any opinions on antlr/jay and/or asm/gnu.bytecode? We should probably also implement a fallback mode (not build all tools) if either dependency isn't available. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
