Hi Tom, On Tue, 2006-11-28 at 15:42 -0700, Tom Tromey wrote: > Tom> Ideally we could just import the ASM sources. I thought this idea was > Tom> rejected, but I can't find a link. I'd like to revisit this, since > Tom> this is the simplest way to solve the problem. And unfortunately it seems upstream recommends this since they don't promise a stable api. sigh. > The code is available from asm.objectweb.org. > > The license is here: > > http://asm.objectweb.org/license.html That looks good. > I would import whatever version currently works. Later we could > import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? I like to go over the sources once and send a report about it to the fsf licensing team so they can OK it for external inclusion (I don't foresee any issues, since it looks like a fairly stable [except for the api...] project with a known upstream). > I'd import the code into classpath/tools/external (a new directory > created for this purpose) and update the build scripts to match. > > I wouldn't rename the classes or anything like that. I would just > import them using their upstream names. This is ok, I think, because > the resulting classes would only end up in tools.zip -- not in > glibj.zip. Users setting CLASSPATH could still have problems, but > this doesn't seem like a major issue. That means we would be exactly the same as upstream so we can easily update if necessary and it won't 'pollute' the bootclasspath package space which is good. Thanks, Mark
Attachment:
signature.asc
Description: This is a digitally signed message part
