[EMAIL PROTECTED] wrote: > On 8/26/08, Reinhard Pötz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ________________________________________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
