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 }
