Are the component configurations part of our contract?

[Daniel Fagerstrom <da...@nada.kth.se>]

Carsten have started to convert some of our components (FileGenerator, 
DOMParser, SAXParser and EntityManager) from Avalon managed to Spring 
managed components. And I'd like to join the work and try to make in the 
first step the pipeline layer and maybe some important blocks Spring 
managed.

The main reasons for this is that it makes our components reusable and 
that it makes it much easier to understand, maintain and develop Cocoon.

An important question here is if we consider the (Avalon) component 
configuration files and the role files as part of our public contract 
and if there should be a deprecation cycle for them.

IMO we shouldn't consider them part of the public contract as:
* the configurations have never been formally specified (e.g. with a 
scheme). And we have never said that it is a fixed contract.
* For the vast majority of users the configuration files have been an 
unwelcome hurdle to maintain and they have only changed a few properties 
and they will prefer to use the property mechanism for this instead of 
editing a vast central configuration file.
* It would be much work for us to maintain both Avalon and Spring 
configurability for our components.

Neither the less I think that the issue has to be discussed before we 
start to POJOfy and Springify the components.

WDYT?

/Daniel

Re: Are the component configurations part of our contract?

[Peter Hunsberger <pe...@gmail.com>]

On 12/30/06, Carsten Ziegeler <cz...@apache.org> wrote:
<snip/>
>
> 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.

Personally, I'd be willing to convert our code.  As far as I'm
concerned you can get rid of ALL the Avalon compatibility.

It seems like a lot of work to make set of wrappers for backward
compatibility, mark them as deprecated (I guess you can't do this in a
2.1.11 as there isn't any replacement yet) and then finally get rid of
everything.  If I'm going to have to do the conversion anyway, might
as well make a clean break of it.

-- 
Peter Hunsberger

Re: Are the component configurations part of our contract?

[Carsten Ziegeler <cz...@apache.org>]

Ralph Goers wrote:
> 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?
Yes, there is no difference from the user's pov.

> 
> 2. Is it possible to take components that compiled in 2.1, recompile 
> them with 2.2 and then configure them and use them?
Yes, in most cases. As long as you use the "public api" of Cocoon this
works. Of course some internal things have changed and if you use
something of that, you have to change your code.

> 
> 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.
Yes, the sitemap itself and its logic work in the same way as 2.1.x.

Carsten
-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Are the component configurations part of our contract?

[Ralph Goers <Ra...@dslextreme.com>]

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

Re: Are the component configurations part of our contract?

[Carsten Ziegeler <cz...@apache.org>]

Daniel Fagerstrom wrote:
> Carsten have started to convert some of our components (FileGenerator, 
> DOMParser, SAXParser and EntityManager) from Avalon managed to Spring 
> managed components. And I'd like to join the work and try to make in the 
> first step the pipeline layer and maybe some important blocks Spring 
> managed.
Great!

I added wrappers for the "old" excalibur interfaces to be compatible, so
for example the excalibur DOMParser implementation uses the pojo
DOMParser etc.

> 
> The main reasons for this is that it makes our components reusable and 
> that it makes it much easier to understand, maintain and develop Cocoon.
> 
> An important question here is if we consider the (Avalon) component 
> configuration files and the role files as part of our public contract 
> and if there should be a deprecation cycle for them.
> 
> IMO we shouldn't consider them part of the public contract as:
> * the configurations have never been formally specified (e.g. with a 
> scheme). And we have never said that it is a fixed contract.
> * For the vast majority of users the configuration files have been an 
> unwelcome hurdle to maintain and they have only changed a few properties 
> and they will prefer to use the property mechanism for this instead of 
> editing a vast central configuration file.
> * It would be much work for us to maintain both Avalon and Spring 
> configurability for our components.
> 
> Neither the less I think that the issue has to be discussed before we 
> start to POJOfy and Springify the components.
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.

Carsten
-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/