On 5 May 2004, at 22: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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
