Moving tools (Was: [cp-patches] FYI: Comitting the RMI daemod (RMID))

Mark Wielaard mark at klomp.org
Sun Apr 2 14:27:57 UTC 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060402/6f771c64/attachment.pgp


More information about the Classpath-patches mailing list