cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cocoon 2.1 showstopper?
Date Tue, 17 Jun 2003 13:10:00 GMT
Nathaniel Alfred wrote:

>>Yes, it's only recompiling - nothing more (well, at least in 
>>theory :) )
>For non-trivial Cocoon sites the 2.0.x to 2.1 migration will require
>more than just recompiling component classes.  
>There are incompatibilities on different levels.  The ones I am aware of
>1.) sitemap.xmap must add <map:pipes> in components definition.
>2.) File upload class name changed from
>o.a.c.components.request.multipart.FilePart to
>3.) File upload method names changed from FilePart.getFilePath() to
>(Need to confirm on this one.  I don't have file upload working yet with
>4.) RequestGenerator changed namespace from
> to

5.) i18nTransformer changed namespace from to

>I don't think it is worthwhile to attempt complete backwards
>compatibilitity in 2.0 to 2.1.  Instead there should be a Migration
>Guide listing the known incompatibilities in a more comprehendable form
>than the Changes file.  Otherwise Cocoon users will be in for a rough
>ride in the migration, possible producing a lot of bad press at this
>crucial moment.

I think this is the way to go, as there are a number of "small 
incompatibilities" that prohibit direct porting from 2.0 to 2.1 on 
non-trivial sites, and ensuring strong back-compatibility seems difficult.

Furthermore, the mentioned byte-code incompatibility introduced by the 
move to LogEnabled doesn't seem the most harmful to me, as a lot of 
Cocoon apps don't define new components. Changes in built-in components 
namespaces mentioned above are IMO much more confusing.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message