cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [cocoon-2.2] Deprecation
Date Wed, 07 Nov 2007 20:52:04 GMT
Carsten Ziegeler pisze:
> Yes, that's true. Now, at some point we have to break compatibility to
> get a cleaner architecture and
> an even better way of doing things. Perhaps removing sub sitemaps is one
>  of these things, perhaps not.

Before we start to think about migration path and embedding 2.1 as "emergency help" for existing
users I really think we should agree what we are going to deprecate and remove in the future
and
most importantly how we envision future Cocoon's architecture so there will be no "perhaps
yes,
perhaps no" doubts any more.

> But on the other hand there are many applications out there using this
> stuff and they don't want to migrate. There is no real benefit for them.
> But there is benefit for them using latest and greatest Cocoon for now
> stuff. And this is very I think embedding 2.1 in 2.2 might make sense.
> It allows people to run their old applications without modifications
> while at the same time they can start new apps with 2.2.

If people don't want to migrate I would tell them to stick to 2.1, it's stable and final release
of
2.2 won't make 2.1 unusable.

> As Cocoon 2.2 uses Spring as the container and as the Cocoon beans are
> added to the Spring root container, these things are available in 2.1
> through Spring as well. So people are able to call 2.2 stuff from within
> 2.1. It might be a thin bridge in terms of possibilities but I think
> going this way makes things easier.

Carsten, haven't you forgotten that in 2.2 all components (even Avalon-based) are managed
by Spring?
I mention this because I can easily imagine clashes between the same components defined both
in 2.1
and 2.2. If you want to make anything usable you must assure collaboration in both ways between
2.1
and 2.2 so all components must be shared and clashes are unavoidable IMHO.

Really, the more I think about this I idea the more obstacles I see but maybe I'm lacking
something.
Anyway, I think that the most important point is made earlier that we must establish goals
we want
to achieve before we start to think about implementation.

Thinking more about incompatibilities between cocoon: and servlet: protocols I'm getting an
impressions that they are not such fundamentally different when it comes to their usage schemes.
Of
course they differ in many details but as Reinhard properly characterized differences comes
from the
fact that servlet: protocol just tries to avoid side-effects cocoon: protocol allows.

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message