You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/05/02 14:55:14 UTC
[all] BinaryCompatability tester
Does anyone know of a tool to test whether a new version of a jar file is
binary compatible with the old version?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This catches source compatability, but not binary compatability. ie. the
ability to run code compiled against an old jar file without recompilation
against the new jar file.
Perhaps its possible to compile the old unit tests against the old jar, and
then run them against the new jar. That might provide some basis of
checking.
Stephen
From: "matthew.hawthorne" <ma...@apache.org>
> Could you do a checkout of the unit tests for the last release, and run
> them against the new jar?
> Stephen Colebourne wrote:
> > Does anyone know of a tool to test whether a new version of a jar file
is
> > binary compatible with the old version?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 2 May 2004, matthew.hawthorne wrote:
> Stephen Colebourne wrote:
> > Does anyone know of a tool to test whether a new version of a jar file is
> > binary compatible with the old version?
>
>
> Could you do a checkout of the unit tests for the last release, and run
> them against the new jar?
Only real good if the unit tests are full though. There are times when the
return type might not be grabbed.
Plus you would want to have a binary version of the unit tests compiled
against the old jar. Compiling against the new jar would screw things up,
so it gets a bit trickier.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by "matthew.hawthorne" <ma...@apache.org>.
Stephen Colebourne wrote:
> Does anyone know of a tool to test whether a new version of a jar file is
> binary compatible with the old version?
Could you do a checkout of the unit tests for the last release, and run
them against the new jar?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
Or even changing parameters?
public String toString(String) to
public String toString(Object)
I imagine anything that is classed as an API change would be a problem for
binary compatibility.
Hen
On Sun, 2 May 2004, Stephen Colebourne wrote:
> jdiff is not a bad option and maybe possible - I'd hoped someone might have
> written one already ;-). One thing to watch out for on binary compatability
> is changing method return types, which breaks binary compatability.
>
> Stephen
>
> > The only thing I can think of is the jdiff tool. As long as things are
> > only added, I would assume binary compatibility is kept?
> >
> > So if jdiff were to create an xml report before the html [it might be able
> > to do this], you could write something to create a different html report
> > that merely cares about binary compatibility.
> >
> > Hen
> >
> > On Sun, 2 May 2004, Stephen Colebourne wrote:
> >
> > > Does anyone know of a tool to test whether a new version of a jar file
> is
> > > binary compatible with the old version?
> > >
> > > Stephen
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Stephen Colebourne <sc...@btopenworld.com>.
jdiff is not a bad option and maybe possible - I'd hoped someone might have
written one already ;-). One thing to watch out for on binary compatability
is changing method return types, which breaks binary compatability.
Stephen
> The only thing I can think of is the jdiff tool. As long as things are
> only added, I would assume binary compatibility is kept?
>
> So if jdiff were to create an xml report before the html [it might be able
> to do this], you could write something to create a different html report
> that merely cares about binary compatibility.
>
> Hen
>
> On Sun, 2 May 2004, Stephen Colebourne wrote:
>
> > Does anyone know of a tool to test whether a new version of a jar file
is
> > binary compatible with the old version?
> >
> > Stephen
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
That would be a cool thing. The last released tag vs HEAD as a binary
compatibility nightly tester.
Definitely something worth working on.
Hen
On Tue, 4 May 2004, robert burrell donkin wrote:
> On 3 May 2004, at 22:38, Simon Kitching wrote:
> > On Mon, 2004-05-03 at 19:15, robert burrell donkin wrote:
>
> <snip>
>
> >> there is a maven jdiff plugin which i've been using to create reports
> >> on the difference between the betwixt refactoring branch and HEAD.
> >> it's
> >> pretty easy to use so maybe that'd be worth trying...
> >
> > jdiff is easy to use????
> >
> > I think it's a nightmare to use. The documentation is almost
> > incomprehensible. Maybe if you know Maven then using the maven plugin
> > might be easier - I was running jdiff directly.
>
> i found that the maven jdiff plugin was very easy to use. just set up a
> couple of properties and take a look at the differences formatted in
> html but don't let that stop you writing something better if you have
> the itch :)
>
> a continuous integration tool (a bit like junit) that tested various
> interfaces for compatibility against a particular CVS tag would be
> useful.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 3 May 2004, at 22:38, Simon Kitching wrote:
> On Mon, 2004-05-03 at 19:15, robert burrell donkin wrote:
<snip>
>> there is a maven jdiff plugin which i've been using to create reports
>> on the difference between the betwixt refactoring branch and HEAD.
>> it's
>> pretty easy to use so maybe that'd be worth trying...
>
> jdiff is easy to use????
>
> I think it's a nightmare to use. The documentation is almost
> incomprehensible. Maybe if you know Maven then using the maven plugin
> might be easier - I was running jdiff directly.
i found that the maven jdiff plugin was very easy to use. just set up a
couple of properties and take a look at the differences formatted in
html but don't let that stop you writing something better if you have
the itch :)
a continuous integration tool (a bit like junit) that tested various
interfaces for compatibility against a particular CVS tag would be
useful.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-05-07 at 12:07, Henri Yandell wrote:
> On Thu, 6 May 2004, robert burrell donkin wrote:
>
> > community rules :)
> >
> > if people are more comfortable with sourceforge (and two are so far, by
> > my count) then that's cool with me.
> >
> > do any (potential) volunteers feel that the sandbox would be better
> > than the sourceforge?
>
> Will answer the rest of the email after more deliberation, but I'm +1 to
> the sandbox as I find sourceforge to be a huge pain to do releases at, and
> this was before they stopped shell access to the CVS repo.
My thoughts were not so much about the development process, but about
where the application will live when released. Commons is a collections
of libraries; there aren't any "commons applications", and I think one
would feel very out-of-place (and possibly be against the charter).
Maybe it could find a home within the Ant project, as one of its
interfaces will be an Ant task? But that might make it harder to find
for people looking for a stand-alone tool...
I'm also concerned by the number of commit messages likely to flood the
commons list. As a new project, there is likely to be a lot more cvs
commit operations than for a "mature" project. None of it is likely to
be of interest to anyone except the 2 or 3 people actually working on
the project.
As long as people aren't concerned about the CVS commit emails issue, I
guess we could *start* in the sandbox, and deal with these issues nearer
to release time if people wish. That would certainly be the path of
least resistance..
I haven't worked on SourceForge before, so don't know how much pain a
release involves there.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 6 May 2004, robert burrell donkin wrote:
> community rules :)
>
> if people are more comfortable with sourceforge (and two are so far, by
> my count) then that's cool with me.
>
> do any (potential) volunteers feel that the sandbox would be better
> than the sourceforge?
Will answer the rest of the email after more deliberation, but I'm +1 to
the sandbox as I find sourceforge to be a huge pain to do releases at, and
this was before they stopped shell access to the CVS repo.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 5 May 2004, at 23:22, Simon Kitching wrote:
<snip>
> 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.
AIUI introspection is for higher level concepts (like the bean naming
conventions) whereas reflection is about the the low level mechanics.
i'm not sure how BCEL fits in since it's better know for byte code
engineering than reflection (but i'm not an expert and i'd be glad to
be educated :)
> 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.
i'd probably advocate decoupling the actual information gathering from
the collation. IMHO we should probably start with reflection (not least
because it's what i know best ;) for the gathering but leave the option
open for a gathering engine based on xdoclet (or something like that)
and one based on BCEL (if that's possible).
> The name is an interesting issue: I see it as both a replacement for
> jdiff and a binary-compatibility reporter. Maybe JarComparer?
if creating (one day) a competitor for jdiff is your aim then maybe
CompareJ might be a reasonable name for the project with products
JarComparer for jars and (one day) SourceComparer for source.
> 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.
i'd probably do for a POJO object model rather than directly to DOM
since these tend to be easier to test and work with (plus there's
usually a lower barrier to entry for newbie developers) but i agree
that xml's the right choice for reporting. i'd probably choose a SAX
pipeline for the output since this can easily transformed or DOM'd as
required. your plans for the actual reporting sound good. your command
line seems about right too.
> 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).
IMHO it's best to go for a manager POJO which can be wrapped in various
ways to create ant tasks, jelly tags, maven plugins etc but yes, you're
right that an ant task is essential...
so we'd probably be looking at:
1 a gathering phase that creates simple object models for the classes
2 an analysis phase that takes two models and calculates the differences
3 an result phase that takes the results and pushes them into a SAX
pipeline
4 a reporting phase that uses stylesheets to create the reports
how does this sound?
> 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.
community rules :)
if people are more comfortable with sourceforge (and two are so far, by
my count) then that's cool with me.
do any (potential) volunteers feel that the sandbox would be better
than the sourceforge?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Thu, 2004-05-06 at 09:53, Stephen Colebourne wrote:
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 5 May 2004, robert burrell donkin wrote:
>
> On 5 May 2004, at 22:53, Stephen Colebourne wrote:
>
> JCompat?
>
> not sure i positively like the name but it seems like a better match.
JarTester. CompatJ. VersionChooser (it could actually tell people what the
version number should be).
> > 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.
>
> that's what it feels to me too but the community rules :)
>
> so if there are enough commons folks who want to work on this too then
> the sandbox would be right...
I'm happy to be involved, it interests me which means I can find time.
Same as Stephen though, time is overpaid.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 5 May 2004, at 22:53, Stephen Colebourne wrote:
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
>>> 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 did think about that first but jdiff exists already (don't want to
replicate the wheel but want this to be ready to use ASAP) and this
could be coded very quickly using jars and reflection.
> I would suggest that the name refer more to the compatability checking
> aspect, as jdiff already does differences. Perhaps JCompat?
JCompat?
not sure i positively like the name but it seems like a better match.
> 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.
that's what it feels to me too but the community rules :)
so if there are enough commons folks who want to work on this too then
the sandbox would be right...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > 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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 3 May 2004, at 22:38, Simon Kitching wrote:
<snip>
> 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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-05-03 at 19:15, robert burrell donkin wrote:
> On 2 May 2004, at 17:47, Henri Yandell wrote:
>
> > The only thing I can think of is the jdiff tool. As long as things are
> > only added, I would assume binary compatibility is kept?
> >
> > So if jdiff were to create an xml report before the html [it might be
> > able
> > to do this], you could write something to create a different html
> > report
> > that merely cares about binary compatibility.
>
> there is a maven jdiff plugin which i've been using to create reports
> on the difference between the betwixt refactoring branch and HEAD. it's
> pretty easy to use so maybe that'd be worth trying...
jdiff is easy to use????
I think it's a nightmare to use. The documentation is almost
incomprehensible. Maybe if you know Maven then using the maven plugin
might be easier - I was running jdiff directly.
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.
However jdiff does (roughly) do the job once you get it working.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 2 May 2004, at 17:47, Henri Yandell wrote:
> The only thing I can think of is the jdiff tool. As long as things are
> only added, I would assume binary compatibility is kept?
>
> So if jdiff were to create an xml report before the html [it might be
> able
> to do this], you could write something to create a different html
> report
> that merely cares about binary compatibility.
there is a maven jdiff plugin which i've been using to create reports
on the difference between the betwixt refactoring branch and HEAD. it's
pretty easy to use so maybe that'd be worth trying...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
The only thing I can think of is the jdiff tool. As long as things are
only added, I would assume binary compatibility is kept?
So if jdiff were to create an xml report before the html [it might be able
to do this], you could write something to create a different html report
that merely cares about binary compatibility.
Hen
On Sun, 2 May 2004, Stephen Colebourne wrote:
> Does anyone know of a tool to test whether a new version of a jar file is
> binary compatible with the old version?
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Here is the report from clirr between collections 2.1 and 3.0 (edited):
It still needs some work, but the basic framework and so on are there.
Commons definitely needs to start using a tool like this (and maybe Gump
too).
Stephen
ERROR: Removed org.apache.commons.collections.iterators.ProxyListIterator
from the list of superclasses of
org.apache.commons.collections.iterators.FilterListIterator
INFO: Method 'public java.util.ListIterator getListIterator()' has been
added in org.apache.commons.collections.iterators.FilterListIterator
INFO: Method 'public void setListIterator(java.util.ListIterator)' has been
added in org.apache.commons.collections.iterators.FilterListIterator
INFO: Added java.util.NoSuchElementException to the list of superclasses of
org.apache.commons.collections.BufferUnderflowException
ERROR: Removed org.apache.commons.collections.iterators.ProxyIterator from
the list of superclasses of
org.apache.commons.collections.iterators.TransformIterator
INFO: Method 'public java.util.Iterator getIterator()' has been added in
org.apache.commons.collections.iterators.TransformIterator
INFO: Method 'public boolean hasNext()' has been added in
org.apache.commons.collections.iterators.TransformIterator
INFO: Method 'public void remove()' has been added in
org.apache.commons.collections.iterators.TransformIterator
INFO: Method 'public void setIterator(java.util.Iterator)' has been added in
org.apache.commons.collections.iterators.TransformIterator
ERROR: Removed org.apache.commons.collections.iterators.ProxyIterator from
the list of superclasses of
org.apache.commons.collections.iterators.FilterIterator
INFO: Method 'public java.util.Iterator getIterator()' has been added in
org.apache.commons.collections.iterators.FilterIterator
INFO: Method 'public void setIterator(java.util.Iterator)' has been added in
org.apache.commons.collections.iterators.FilterIterator
ERROR: Removed org.apache.commons.collections.iterators.ProxyIterator from
the list of superclasses of
org.apache.commons.collections.iterators.UniqueFilterIterator
ERROR: Removed org.apache.commons.collections.DefaultMapEntry from the list
of superclasses of org.apache.commons.collections.BeanMap$MyMapEntry
ERROR: Return type of Method 'public java.util.ListIterator
emptyListIterator()' has been changed to
org.apache.commons.collections.ResettableListIterator in
org.apache.commons.collections.IteratorUtils
ERROR: Return type of Method 'public java.util.Iterator
singletonIterator(java.lang.Object)' has been changed to
org.apache.commons.collections.ResettableIterator in
org.apache.commons.collections.IteratorUtils
ERROR: Return type of Method 'public java.util.Iterator emptyIterator()' has
been changed to org.apache.commons.collections.ResettableIterator in
org.apache.commons.collections.IteratorUtils
ERROR: Return type of Method 'public java.util.Iterator
arrayIterator(java.lang.Object[])' has been changed to
org.apache.commons.collections.ResettableIterator in
org.apache.commons.collections.IteratorUtils
ERROR: Return type of Method 'public java.util.Iterator
arrayIterator(java.lang.Object[], int)' has been changed to
org.apache.commons.collections.ResettableIterator in
org.apache.commons.collections.IteratorUtils
ERROR: Return type of Method 'public java.util.Iterator
arrayIterator(java.lang.Object[], int, int)' has been changed to
org.apache.commons.collections.ResettableIterator in
org.apache.commons.collections.IteratorUtils
From: "Stephen Colebourne" <sc...@btopenworld.com>
> This seems especially relevant with both collections and logging issues
> recently.
>
> From Lars Kuhne, developer of clirr
> > I'd say that the current version number 0.2 reflects the development
> > status pretty well: Alpha
> >
> > * somewhat usable (detects many compatibility errors already)
> > * some compatibility problems are currently not detected
> > * probably not configurable enough for many users
>
> It seems to be a good starting point for building this, so if anyone wants
> to volunteer, Lars would be pleased to receive patches. Its LGPL, but for
a
> tool this shouldn't matter to anyone.
>
> Stephen
>
> From: "Henri Yandell" <ba...@generationjava.com>
> > http://clirr.sourceforge.net/ looks interesting by the way. Just noticed
> > it on Vincent Massol's blog.
> >
> > On Sun, 2 May 2004, Stephen Colebourne wrote:
> >
> > > Does anyone know of a tool to test whether a new version of a jar file
> is
> > > binary compatible with the old version?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-05-21 at 07:18, Stephen Colebourne wrote:
> This seems especially relevant with both collections and logging issues
> recently.
>
> >From Lars Kuhne, developer of clirr
> > I'd say that the current version number 0.2 reflects the development
> > status pretty well: Alpha
> >
> > * somewhat usable (detects many compatibility errors already)
> > * some compatibility problems are currently not detected
> > * probably not configurable enough for many users
>
> It seems to be a good starting point for building this, so if anyone wants
> to volunteer, Lars would be pleased to receive patches. Its LGPL, but for a
> tool this shouldn't matter to anyone.
>
> Stephen
>
> From: "Henri Yandell" <ba...@generationjava.com>
> > http://clirr.sourceforge.net/ looks interesting by the way. Just noticed
> > it on Vincent Massol's blog.
> >
> > On Sun, 2 May 2004, Stephen Colebourne wrote:
> >
> > > Does anyone know of a tool to test whether a new version of a jar file
> is
> > > binary compatible with the old version?
Hi All,
I just wanted to let people know that (as discussed on this list a few
weeks ago) I'm working on a similar tool. The current working title is
"JCompare".
The code isn't yet ready for prime time. In fact, I wouldn't have sent
this email but for the discussion about clirr. However JCompare is
generating some useful output already. Here is a link to a comparison of
Digester 1.5 vs the current Digester CVS head (which will hopefully
become Digester 1.6 real soon now):
http://www.apache.org/~skitching/digester-15-16.txt
JCompare is currently licensed under the APL2.0. Note that I don't have
anything against LGPL, particularly for "applications"; it's simply that
I want to keep the option open of having this code become an ASF
project.
What this license difference means is that anyone who contributes to
"clirr" (LGPL) may not be able to later contribute to JCompare. That's
unfortunate but I don't see any way around this.
I have had a brief look at clirr. From what I can see, clirr is focussed
on reporting "compatible/not-compatible" status, and will probably have
trouble generating good difference reports. JCompare is focussed on
generating difference reports, and my next task is to determine how (if)
I can add binary compatibility testing to this. So in the end, the two
projects may end up complimentary to each other.
The clirr code is certainly a little tidier at this moment. I am still
"exploring" the problem, so JCompare will no doubt go through a number
of structural refactorings before becoming stable. And there are heaps
of missing features. However if people do want to look at the existing
code, it is here:
http://www.apache.org/~skitching/jcompare.tgz
Clirr and JCompare both take a similar approach: Clirr uses BCEL to
parse .class files, while JCompare uses ASM (asm.objectweb.org). However
clirr uses an extensible list of "checker" tasks to check for certain
issues, while JCompare is currently more "monolithic". These are early
days, however, and this may change.
I don't currently wish to merge efforts with clirr because (as I noted
above) I am not sure that the clirr architecture is suitable for
generating good reports. And once I start working on an LGPL library for
comparing jars it will be difficult legally to start work on an
ASF-licensed alternative.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This seems especially relevant with both collections and logging issues
recently.
>From Lars Kuhne, developer of clirr
> I'd say that the current version number 0.2 reflects the development
> status pretty well: Alpha
>
> * somewhat usable (detects many compatibility errors already)
> * some compatibility problems are currently not detected
> * probably not configurable enough for many users
It seems to be a good starting point for building this, so if anyone wants
to volunteer, Lars would be pleased to receive patches. Its LGPL, but for a
tool this shouldn't matter to anyone.
Stephen
From: "Henri Yandell" <ba...@generationjava.com>
> http://clirr.sourceforge.net/ looks interesting by the way. Just noticed
> it on Vincent Massol's blog.
>
> On Sun, 2 May 2004, Stephen Colebourne wrote:
>
> > Does anyone know of a tool to test whether a new version of a jar file
is
> > binary compatible with the old version?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] BinaryCompatability tester
Posted by Henri Yandell <ba...@generationjava.com>.
http://clirr.sourceforge.net/ looks interesting by the way. Just noticed
it on Vincent Massol's blog.
Hen
On Sun, 2 May 2004, Stephen Colebourne wrote:
> Does anyone know of a tool to test whether a new version of a jar file is
> binary compatible with the old version?
>
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org