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" <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
