Carsten Ziegeler wrote:
Yes, I was just in the process to write an email with a similar topic as
I noted a problem while reading Ralphs last post in the "Re:
Configuration handling in 2.2 (properties etc.)" thread.
First of all, 2.2 should be as compatible to 2.1.x as possible. I guess
we all agree to this. The important question is of course what "as
compatible as possible" means :)
We should provide the same set of components as 2.1.x registered with
the same roles. This will ensure that existing applications should work
without any code changes.
As you outlined above, I think we should not strive for requiring that
even the configuration of these components is the same as in 2.1.x. I
see no real sense for this. We broke this contract from one 2.1.x to the
next release already. 2.2 has superior configuration mechanisms and
features so we should enable them.
Now, there is one problem though (and I didn't realize this until I read
Ralphs mail :( ): sitemap components. Today, user have sitemaps with
component configurations for sitemap components; these should imho work
without changes, but this requires that we can't change the sitemap
components from avalon to pojos as I already did with the FileGenerator...
So, I fear we should have a compatibility set of Avalon components and
add additional pojo replacements for them one by one. If we add a pojo
alternative we deprecate the avalon component.
Since I don't know the details about how this is all being done I'll
just ask some questions.
1. Is it possible to declare the generators, transformers, etc as beans
and reference them by the same id (i.e. the role name) in the sitemap as
has always been done?
2. Is it possible to take components that compiled in 2.1, recompile
them with 2.2 and then configure them and use them?
If the answer to both of these is yes then I don't see a problem. I
don't think it is a big deal to require that all component definitions
move out of the sitemap and be declared as Spring beans (or whatever).
However, the "logic" of a sitemap should not have to change. That would
be a real pain.
In my view, the definition of moving from one minor release to the next
means that a recompile is necessary as well as some other minor
changes. However, given that users of Cocoon will also (presumably)
want to switch to Maven 2 this release is a bit more intrusive than one
would expect. Frankly, I think it is a mistake that it won't be 3.0
given all the architectural changes that have taken place. If it was we
wouldn't even be having this conversation.
Ralph
