Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Cocoon 2.1 showstopper?
Date: Tue, 17 Jun 2003 15:43:56 +0200
Message-ID: <LKENJPKDAIKAPKHEOCMMOEGCDPAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3EEF1328.3040706@anyware-tech.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

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 }
>
>