cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: Where is cocoon going ?
Date Fri, 29 Aug 2008 22:26:49 GMT
solprovider@apache.org wrote:
> On 8/26/08, Reinhard Pötz <reinhard@apache.org> wrote:
>> 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
>>    (http://www.indoqa.com/en/people/reinhard.poetz/blog/625)
>>
>>   . 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
>>    logging.
>>
>>    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.
>>  HTH
>>  Reinhard Pötz                           Managing Director, {Indoqa} GmbH
> 
> From your blog:
> Now it's official: Corona, the reimplementation of Cocoon which is
> currently available in the Cocoon whiteboard has been accepted by the
> Cocoon PMC and will become Apache Cocoon 3, the next major version of
> Cocoon!
> AND
> The first alpha release of Cocoon 3 is at the ready.
> 
> From Mark's summary:
> 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".
> AND
> 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.
> 
> I was Mark's "somebody" suggesting Cocoon-X.Y (while recommending X.Y
> = 2.7 to avoid this confusion.)  The project chose X.Y = 3.0.  IIUC,
> Cocoon 3 is not ready to replace Cocoon 2, has not been officially
> declared the successor to Cocoon 2, and may still be aborted or become
> a different project.. Did I miss the memo?

I'm not sure if I understand what you want to know. There was a vote by
the Cocoon PMC with the result that Corona will become Cocoon 3 (see
http://cocoon.markmail.org/message/txav36lmvpkpbso4).

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message