You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Nick Baumberger <nb...@yahoo.com> on 2008/08/24 22:34:32 UTC
Where is cocoon going ?
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 ?
Wading half a day through the more recent mail archive I couldn't realy trace a consensus discussion but found only alerting comments such as those from Grzegorz Kassowski in
http://article.gmane.org/gmane.text.xml.cocoon.devel/74571
Quote: "When approaching ROA design we need to throw out continuations of course".
Does this whole discussion around ROA and RESTful design principles concern just blocks or the cocoon core ? Are these issues so essential that cocoon can't proceed without taking them into account, or is it just a programming hype of the new developers avantgard ?
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Where is cocoon going ?
Posted by Mark Lundquist <lu...@gmail.com>.
On Aug 26, 2008, at 5:31 AM, Ken Starks wrote:
> And if so, in spite of the general consensus that 2.2 is the way
> forward, should I
> just stick to the 2.1.11 (which satisfies my current needs) until
> Corona catches up. ?
Hi Ken, I would say that there are only two reasons to ever upgrade.
You would upgrade (a) if you need specific features or bug fixes in a
subsequent release, or (b) to "amortize" your learning curve... i.e.
if you feel that someday you will be facing (a), you might not want to
wait until you are 5 releases behind the curve and have to catch up,
when you'd be like those guys that post here saying "Can somebody help
me upgrade my Cocoon 1.0.8 application? I'm kinda worried about all
my XSP logicsheets and custom sitemap Actions..." and most of the
people on the list weren't even _born_ when Cocoon 1.0.8 was released
(kidding :-). So alternatively, you could have a policy of taking
every upgrade no matter what — even though those point upgrades might
entail some work, and may also expose you to new bugs — even though
you don't get any immediate value out of it.
Or as someone has said (not in regard to software but it certainly
applies here as well): "when the pain of the status quo exceeds the
pain of change, then you change." :-)
So it's a judgement call. But I would say that if you really feel
completely happy with 2.1.11, and 2.2 has nothing to offer you right
now, then... you should stay with 2.1.11. Even if Corona/C3.x should
"catch up" someday... unless you feel at that point that it offers you
something you need/want. But if you do upgrade to 2.2, then I think I
would consider going to the "stay up with the current release"
strategy, especially since in the 2.2 world a lot of upgrading is
covered by "update a bunch of Maven artifact version numbers in your
POM".
cheers & HTH,
—ml—
PS — FYI, I'm on the cusp of upgrading a whole slew of applications
built on Cocoon 2.1.8 up to 2.2.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Where is cocoon going ?
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Bertrand Delacretaz wrote:
> On Tue, Aug 26, 2008 at 11:29 AM, Ken Starks <ke...@lampsacos.demon.co.uk> wrote:
>
>
>> ...Aren't these objectives part of Cocoon 22 also ? I though part of the
>> rationale for blocks was that
>> they are--beyond a small core-- optional and modular, you don't have to
>> have any you don't need.
>>
>> So building a 'lightweight' cocoon App would be part of Cocoon 22
>> already. Or are the core
>> dependencies of 2.2 already too heavy a footprint ?...
>>
>
> I think the main difference is that Corona (er...Cocoon 3) is much
> easier to embed and use from other frameworks, as its core has very
> few external dependencies.
>
> That's an important criteria for people who just want to use the nice
> Cocoon stuff (pipelines mostly, in my case) in other environments, as
> opposed to building apps completely on Cooon.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
ah, 'Nice Cocoon Stuff'.
Well for me that is also pipelines mostly. but also:-
For the start of the pipeline, Read-access to a relational database, and
simple access to remote
services such as SOAP. I am not bothered much about write access to the
data-base in Cocoon.
At present I don't much use either aggregation or continuations,
although i have dabbled in
them and like them both.
It looks to me as if 'Virtuoso' might overtake Cocoon as a kind of
universal data-source
for the start of a pipeline. Possibly not, it looks like quite a hefty
bit of gear to have
on the same server as cocoon.
I shall certainly check it out. http://docs.openlinksw.com/virtuoso/
... but as the manual is a few _thousand_ pages, possibly not today.
In the pipeline, I also like i18n, and a smattering of sitemap logic.
At the end of the pipeline I shall want FOP, although I may also
out-source some serialization to something outside of cocoon.
Will Corona have that lot in its 'Nice Cocoon Stuff' ?
And if so, in spite of the general consensus that 2.2 is the way
forward, should I
just stick to the 2.1.11 (which satisfies my current needs) until
Corona catches up. ?
Yours sincerely,
Ken.
Re: Where is cocoon going ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Aug 26, 2008 at 11:29 AM, Ken Starks <ke...@lampsacos.demon.co.uk> wrote:
> ...Aren't these objectives part of Cocoon 22 also ? I though part of the
> rationale for blocks was that
> they are--beyond a small core-- optional and modular, you don't have to
> have any you don't need.
>
> So building a 'lightweight' cocoon App would be part of Cocoon 22
> already. Or are the core
> dependencies of 2.2 already too heavy a footprint ?...
I think the main difference is that Corona (er...Cocoon 3) is much
easier to embed and use from other frameworks, as its core has very
few external dependencies.
That's an important criteria for people who just want to use the nice
Cocoon stuff (pipelines mostly, in my case) in other environments, as
opposed to building apps completely on Cooon.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Where is cocoon going ?
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
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 ?
>
> 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.
>
<snip>
> 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 :-)
>
> cheers,
> —ml—
>
Aren't these objectives part of Cocoon 22 also ? I though part of the
rationale for blocks was that
they are--beyond a small core-- optional and modular, you don't have to
have any you don't need.
So building a 'lightweight' cocoon App would be part of Cocoon 22
already. Or are the core
dependencies of 2.2 already too heavy a footprint ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Where is cocoon going ?
Posted by Alfred Nathaniel <an...@apache.org>.
On Sat, 2008-08-30 at 00:26 +0200, Reinhard Pötz wrote:
> 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).
The vote was about whether Corona may be called Cocoon3. Whether it
will become "the next big thing after Cocoon2.2" as the name suggests,
only time will tell.
Cheers, Alfred.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Where is cocoon going ?
Posted by Reinhard Pötz <re...@apache.org>.
solprovider@apache.org wrote:
> On 8/26/08, Reinhard Pötz <re...@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
Re: Where is cocoon going ?
Posted by so...@apache.org.
On 8/26/08, Reinhard Pötz <re...@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?
solprovider
Re: Where is cocoon going ?
Posted by Reinhard Pötz <re...@apache.org>.
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
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
Re: Where is cocoon going ?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 25, 2008, at 6:34 PM, Mark Lundquist wrote:
> 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! :-)
I love it :) Great write up, Mark, and everything is correct :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11 and XSLTC
Posted by Alfred Nathaniel <an...@apache.org>.
On 2008/08/29 at 09:32 "Laurent Medioni" <lm...@odyssey-group.com> wrote:
> is it reasonable to set the default xslt processor to XSLTC in
> cocoon.xconf ?
> It seams to provoke some weird side effects in my case*
> Would it be a *common* change of the standard configuration ?
> (or is this why the standard xconf does not propose it ;))
I can confirm that XSLTC can be used with Cocoon 2.1.x. However, you
first have to check your stylesheets for XSLTC compatibility. The XSLTC
engine and interpreted Xalan have little more in common than being part
of the same Apache project.
XSLTC flags a number of XSLT constructs are errors, which pass through
Xalan without problems. One example is to call a non-existing template
name from a template which is never executed.
First you should use the command line tool "xalan -xsltc" to check that
your stylesheets compile without error, and then try again with Cocoon.
HTH, Alfred.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11 and XSLTC
Posted by Derek Hohls <DH...@csir.co.za>.
Maybe not so common... but if you want a response from the
developers - who are very active on this list - you may need to
post something more specific (preferably with error logs) than
"seams to provoke some weird side effects".
>>> On 2008/08/29 at 09:32, in message
<19...@mail4.oams.com>, "Laurent
Medioni" <lm...@odyssey-group.com> wrote:
Hi,
Should I transfer this question to the Cocoon developers list ?
I thought I could get some answers from user experiences* I cannot
believe everybody uses the default configuration ;)
Or is it so a dumb question* ? ;)
Thanks.
From:Laurent Medioni [mailto:lmedioni@odyssey-group.com]
Sent: mardi, 26. août 2008 11:08
To: users@cocoon.apache.org
Subject: Cocoon 2.1.11 and XSLTC
Hi,
is it reasonable to set the default xslt processor to XSLTC in
cocoon.xconf ?
It seams to provoke some weird side effects in my case*
Would it be a *common* change of the standard configuration ?
(or is this why the standard xconf does not propose it ;))
Thanks.
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11 and XSLTC
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hi,
Should I transfer this question to the Cocoon developers list ?
I thought I could get some answers from user experiences... I cannot believe everybody uses the default configuration ;)
Or is it so a dumb question... ? ;)
Thanks.
________________________________
From: Laurent Medioni [mailto:lmedioni@odyssey-group.com]
Sent: mardi, 26. août 2008 11:08
To: users@cocoon.apache.org
Subject: Cocoon 2.1.11 and XSLTC
Hi,
is it reasonable to set the default xslt processor to XSLTC in cocoon.xconf ?
It seams to provoke some weird side effects in my case...
Would it be a "common" change of the standard configuration ?
(or is this why the standard xconf does not propose it ;))
Thanks.
____________________________________________________________
* This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
* Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
* Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
* An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
* If you have received this email in error, please notify the sender immediately
and delete the original.
____________________________________________________________
This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
If you have received this email in error, please notify the sender immediately
and delete the original.
Cocoon 2.1.11 and XSLTC
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hi,
is it reasonable to set the default xslt processor to XSLTC in
cocoon.xconf ?
It seams to provoke some weird side effects in my case...
Would it be a "common" change of the standard configuration ?
(or is this why the standard xconf does not propose it ;))
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Where is cocoon going ?
Posted by Mark Lundquist <lu...@gmail.com>.
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 :-)
cheers,
—ml—