On Thu, 2004-05-06 at 09:53, Stephen Colebourne wrote:
> From: "robert burrell donkin" <[EMAIL PROTECTED]>
> > > In fact it's so horrible that I'm thinking of writing an alternative. A
> > > simple app which takes two jars and generates an xml report of the API
> > > differences between them (including listing binary incompatibilities)
> > > should not be too hard.
> >
> > given the experience of the last few weeks, i'd say that this now
> > sounds almost essential. i'd be keen to help create something like
> > this.
> >
> > seems to me that it's split down the middle into:
> >
> > 1 a tool that finds all the classes in a jar and loads
> > 2 a class API differ using reflection
> >
> > sounds (at first glance) that this should be pretty doable.
> >
> > anyone else interested in helping? (if so, i'll start a new sandbox
> > component, if not i'll probably create a project on sourceforge.)
> >
> > anyone have a better name than JarDiffer?
>
> An alternative approach is to build on jdiff. jdiff (via maven) produces by
> default an xml dump of two tagged versions of an API from CVS. This could be
> queried, and the relevant rules applied without needing to have the jar
> files, class files or reflection.
>
> I would suggest that the name refer more to the compatability checking
> aspect, as jdiff already does differences. Perhaps JCompat?
>
> I can't commit to help code though, as I'm struggling as it is. This is
> needed though. Whether it is commons is perhaps questionable - sourceforge
> feels more appropriate.
I'm definitely willing to work on this. I have one project I need to
finish first (a few weeks work) but am then keen to get stuck in.
I also think it is quite doable, not a huge project. I would like to
avoid basing it on jdiff, because jdiff's approach is to use the javadoc
engine, which means access to the source for the jars being compared
plus a whole lot of complexity (the doclet API isn't trivial). I was
thinking more on the lines of Robert's suggestion - just dive into the
jars, use BCEL to do introspection (or is it reflection?) on the classes
in there. The only drawback I see on this is that you don't get access
to @deprecated information. But the simplicity of pointing the tool at
two sets of jars (prev-version and curr-version) rather than two source
trees seems worth it to me. Plus the performance difference should be
significant.
The name is an interesting issue: I see it as both a replacement for
jdiff and a binary-compatibility reporter. Maybe JarComparer?
Here's a rough outline as I see it:
java JarComparer
-oldversion foo-1.jar:bar-1.jar:baz-1.jar
-newversion foo-2.jar:bar-2.jar:baz-2.jar
-shared widgets.jar:parser.jar
-style html
This generates a DOM representation of all the differences and of any
binary incompatibilities found, then runs a stylesheet over it to
generate a report. Standard stylesheets are provided to generate text,
html or xml output, or a user can specify their own stylesheet.
It also needs to be packaged as an Ant task that returns success/failure
depending on user needs (eg fail if any binary incompatibilities found).
I agree with Stephen that SourceForge seems a more natural home for this
tool than jakarta-commons, though I am willing to be persuaded. There's
certainly nothing to prevent us from using the APL 2.0.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
