cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: Where is cocoon going ?
Date Tue, 26 Aug 2008 10:36:51 GMT
Mark Lundquist wrote:
> On Aug 24, 2008, at 1:34 PM, Nick Baumberger wrote:
>> Dear Cocoon-ers,
>> Can somebody tell me where cocoon is heading after release 2.2 ? I did
>> not follow the mailing list for around a year, being back now I am
>> shocked by the recent announcement regarding cocoon 3 which seems to
>> me a complete break with what has been achieved so far - or have I
>> just missed something ? 
> Okay, here is the deal as far as I understand it.  I'm not a Cocoon
> committer, but I sort of follow the dev list, and I feel pretty
> confident that I can answer your question.  Arguably one of the
> committers should answer this, but they haven't so I'll take a whack at
> it.  I should probably dig up pointers to threads in the mail archives
> for you... but I'm not going to, because I am too lazy, sorry! :-)
> Anyway — over the last few years there have been many discussions as
> well as a couple of experiments in the directions of (a) making Cocoon
> more lightweight (e.g. fewer dependencies, smaller memory footprint
> and/or less configuration) and/or simpler (in design and/or usage),
> and/or (b) just recasting the core concepts of Cocoon (e.g. pipeline,
> sitemap etc.) into different forms to see what sort of system would
> result and what it would be like to use.  Sorry for all the "and/or"s in
> there, but anyway, you get the idea.  I remember Antonio Gallardo's
> "Butterfly" (I think that was his project) along these lines.  These can
> be thought of as "R&D" for Cocoon; my impression with them has been that
> of "science fair projects" to explore and gain experience with ideas and
> approaches.
> The latest of these was last year.  A couple of Cocoon committers got
> together with one other guy who wasn't a Cocoon committer, and they said
> "let's see if we can't trim Cocoon down and simplify it", and they had
> some core things that in mind they cared about and some other things
> they were willing to just leave out in the interest of keeping things
> simple.  So they started work on this, and after a pretty short period
> of time realized that what they had come up with was a rewrite of a lot
> of the important parts of Cocoon, plus a little some new stuff, minus a
> whole lot of stuff that (a) they didn't need, and/or (b) hadn't figured
> out what to do with yet or whether/how it would fit in what what they
> had just created.  So they didn't really start out intending to rewrite
> Cocoon; it was supposed to be more of just a refactoring, but in the end
> it turned out to be a "fait accompli" rewrite, albeit an incomplete one.
> So now they had to figure out what to do with this thing they had
> created, so they showed it around to the rest of the Cocoon dev
> community, and the consensus was that it was pretty cool and deserved to
> benefit from continued development.  So then they had to figure out what
> to call it, and this was really motivated by nuts-and-bolts concerns
> about what to call things in the Subversion repository, what to call the
> Maven artifacts, etc.  There was a necessity to nail down this "naming"
> question, driven by some immediate, pragmatic concerns.  The thing
> everyone agreed on was this the new thing was still half-baked or at
> least going to be a work in progress for some time, and nobody knew (and
> I think they still don't know) whether or when it was going to be able
> to "become Cocoon".  The thing had originally been called "Corona", but
> apparently there was some legal jeopardy associated with continuing with
> that name, e.g. publishing artifacts under it, and so the search began
> for a new code name, and there were long threads of discussion in which
> many new possible code names were suggested and then shot down for
> reasons such as being lame-sounding, or already in use by some other
> project/product/company, or being suggestive of something unpleasant in
> some other language, etc., etc. until everybody was just worn out and
> sick of the whole discussion.
> So then somebody said "why don't we just call it Cocoon X.Y" where X.Y
> is far enough out beyond "2.2" that the current lineage of releases
> based on trunk is not going to "run into" X.Y any time soon. That way,
> either 
> (a) Cocoon X.Y will turn out to be just a big brain-fart that doesn't
> amount to anything; in that case the releases would end up just skipping
> "around" X.Y, e.g. from X.Y-1 to X.Y+1, or whatever the case may be; or,
> (b) Cocoon X.Y..Y+n will turn out to be the golden path to Cocoon
> nirvana, in that case it will mature to where everything we reasonably
> need from Cocoon will be there, e.g. the blocks will all work or be able
> to be made to work; in that case, Cocoon 2.* would go into "maintenance
> mode" (much like 2.1.* today), and Cocoon X.Y+n would be blessed as the
> future of Cocoon.
> (c) Cocoon X.Y could develop into something that is clearly something
> quite different from Cocoon and will have to go forward as an offshoot
> of Cocoon.  Well, in that case they will be back to that unwelcome task
> of coming up with a new name, but at least they will have stalled it off
> for a while and they will only be doing it if they really need to.
> There was an opinion from some legal advisor to the ASF who basically
> said that they only legally safe name for anything having to do with
> Cocoon was "Cocoon", and I'll bet somebody could even take us to court
> over that if the mood struck (kidding, I just made that last part up).
>  Anyway, that sort of sealed the deal and it was decided that "X" would
> be "3" and Y would be "0", so there you have it... "Cocoon 3.0".
> The objection was raised that calling it "Cocoon 3.0" would create FUD
> and confusion within the user community, and that people would see
> "Cocoon 3.0" and think that means "Cocoon 2.2" is a dead-end, or
> deprecated, "circling the drain", etc. (take your pick! :-) even thought
> that certainly /not/ the case!  Or that people would say "gee, I guess I
> should skip upgrading to Cocoon 2.2 and wait for this Cocoon 3.0".
>  That's not the intent!  It's not clear yet that Cocoon 3.x will be able
> to take the place of 2.2, and if it does you could be waiting a long
> time, quite possibly over several release cycles of the 2.2 lineage.
> The answer to that objection was "yeah, but... then we'd have to come up
> with a name for the new thing, and we already tried that."  And there
> was no good answer for that answer.
> So basically: the long and short of it is, there is this thing called
> Cocoon 3.0 and it's called that because the Cocoon developers weren't
> clever enough to think of a good name! :-)  
> What will the new  thing turn out to be?  Nobody's quite sure yet, but
> it's pretty much agreed that it shouldn't affect anybody's decision
> process w.r.t. whether to stay with Cocoon, whether to upgrade from
> 2.1.x to 2.2.0, etc.
> That's my story based on my interpretation of the email threads I've
> followed on the dev list over the last few years (especially recent
> months), I hope it helps.  Hopefully some developer(s) can chime in here
> and let you know whether I've actually clarified things, or muddied the
> waters even worse :-)

Yes, that's a good summary of what happened.

Let me add and underline a few things:

 . Cocoon 3 isn't a 1:1 replacement for Cocoon 2.2. It was developed
   under the assumption that web development has changed

 . Cocoon 3 can be run in parallel with Cocoon 2.2. Thanks to the
   Servlet-Service framework there is also a standardized contract
   for the communication between the two 'worlds'.

 . The Cocoon 3 pipelines module can be used from within any Java
   environment because it doesn't have any dependencies except Commons

   Some of us really tried to rewrite Cocoon 2.x to get to this point,
   but gave up because of the complexity of this task.


Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message