cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Cocoon 2.1 showstopper?
Date Tue, 17 Jun 2003 13:43:56 GMT
Thanks Sylvain and Nathaniel for the points, I added them to our updating
docu.

If you know some more incompatible changes, please either edit directly
the updating doc or send a simple patch.

Thanks
Carsten

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Tuesday, June 17, 2003 3:10 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Cocoon 2.1 showstopper?
>
>
> Nathaniel Alfred wrote:
>
> >>Yes, it's only recompiling - nothing more (well, at least in
> >>theory :) )
> >>
> >>Carsten
> >>
> >>
> >
> >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
> >are:
> >
> >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
> >o.a.c.servlet.multipart.Part.
> >
> >3.) File upload method names changed from FilePart.getFilePath() to
> >Part.getUploadName().
> >(Need to confirm on this one.  I don't have file upload working yet with
> >M2.)
> >
> >4.) RequestGenerator changed namespace from
> >http://xml.apache.org/cocoon/requestgenerator/2.0 to
> >http://apache.org/cocoon/request/2.0.
> >
>
> 5.) i18nTransformer changed namespace from
> http://apache.org/cocoon/i18n/2.0 to http://apache.org/cocoon/i18n/2.1
>
> >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
>
> --
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>


Mime
View raw message