I don't think this really is a showstopper, but it's certainly worth letting folks know about it in the migration path from 2.0 to 2.1.
Let's say there are broadly two kinds of projects that use Cocoon... 1) Projects built on 2.0 that have been "set in stone" with only minor maintenence updates. Essentially if they don't want to upgrade they don't have to. If they do want to upgrade, I would suggest they'll have to recompile and re-test pretty much everything anyway. 2) Projects that are in active development. These will (more than likely) be using 2.1 code base and will therefore not be affected. Are there any projects out there that fall through the cracks? ----- Original Message ----- From: "Carsten Ziegeler" <[EMAIL PROTECTED]> To: "Cocoon-Dev" <[EMAIL PROTECTED]> Sent: Sunday, June 15, 2003 11:20 PM Subject: Cocoon 2.1 showstopper? > Hi, > > I think I found a showstopper for 2.1 :( : > 2.1 is not binary compatible to 2.0.x - if you compile a (sitemap) > component using 2.0.x and put this into 2.1 it will in most cases > fail to run. As a simple example, you can use the FileGenerator.class > from 2.0.x. > > Why is this so? Well, the reason is the change from Loggable > to LogEnabled. If you write your own sitemap component, > you most likely use the provided abstract classes (e.g. AbstractGenerator > or ComposerGenerator). In 2.0.4 these classes inherited from > AbstractLoggable - in 2.1 they inherit from AbstractLogEnabled. > Both offer the same method but with a different return type, > so if you use a component compiled for 2.0.4 in 2.1 it looks for the > getLogger() method of AbstractLoggable and does not find one > with a matching signature. Bang. > > I think, mostly this affects own sitemap components inheriting from > the provided classes, but of course this can occur with every > class where we changed from Loggable to LogEnabled. > > We could solve this problem for sitemap components but not in > general, I fear. > > So, the question is: do we want to have this kind of compatibility > or do the users have to recompile (which works of course as we are > compatible on the source level)? > > Carsten > > Carsten Ziegeler > Open Source Group, S&N AG > http://radio.weblogs.com/0107211/ >
