You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2008/08/06 13:19:50 UTC
[vote] Cocoon 3.0
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
This means that any reference on Corona in source files, package names,
artifact ids, group ids or anywhere else will be dropped and the
standard Cocoon namespace org.apache.cocoon will be used.
This majority vote stays open for 72 hours.
Please cast your votes.
Here is my +1
--
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
________________________________________________________________________
Re: [vote] Cocoon 3.0
Posted by Felix Knecht <fe...@apache.org>.
Reinhard Pötz schrieb:
>
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
+1
Felix
Re: [vote] Cocoon 3.0
Posted by Ralph Goers <Ra...@dslextreme.com>.
+1
Reinhard Pötz wrote:
>
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files, package
> names, artifact ids, group ids or anywhere else will be dropped and
> the standard Cocoon namespace org.apache.cocoon will be used.
>
> This majority vote stays open for 72 hours.
>
> Please cast your votes.
> Here is my +1
>
Re: [vote] Cocoon 3.0
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-08-06 at 13:19 +0200, Reinhard Pötz wrote:
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
+1
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: [vote] Cocoon 3.0
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 6, 2008 at 1:19 PM, Reinhard Pötz <re...@apache.org> wrote:
>
> ...Following the result of our recent discussion about the future of Corona, I
> propose Corona to become Cocoon 3....
+1
-Bertrand
Re: [vote] Cocoon 3.0
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, Aug 6, 2008 at 6:19 AM, Reinhard Pötz <re...@apache.org> wrote:
>
> Following the result of our recent discussion about the future of Corona, I
> propose Corona to become Cocoon 3.
>
+1
Seems a little weird but I certainly don't have any better alternatives.
--
Peter Hunsberger
Re: [vote] Cocoon 3.0
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 6, 2008, at 7:19 AM, Reinhard Pötz wrote:
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files, package
> names, artifact ids, group ids or anywhere else will be dropped and
> the standard Cocoon namespace org.apache.cocoon will be used.
>
> This majority vote stays open for 72 hours.
>
> Please cast your votes.
+1
Vadim
Re: [vote] Cocoon 3.0
Posted by Carsten Ziegeler <cz...@apache.org>.
+1
Carsten
Reinhard Pötz wrote:
>
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files, package names,
> artifact ids, group ids or anywhere else will be dropped and the
> standard Cocoon namespace org.apache.cocoon will be used.
>
> This majority vote stays open for 72 hours.
>
> Please cast your votes.
> Here is my +1
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [summary][vote] Cocoon 3.0
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 10, 2008, at 4:19 PM, Reinhard Pötz wrote:
> Vadim Gritsenko wrote:
>> On Aug 10, 2008, at 4:19 AM, Reinhard Pötz wrote:
>>> Reinhard Pötz wrote:
>>>> Following the result of our recent discussion about the future of
>>>> Corona, I propose Corona to become Cocoon 3.
>>>> This means that any reference on Corona in source files, package
>>>> names, artifact ids, group ids or anywhere else will be dropped
>>>> and the standard Cocoon namespace org.apache.cocoon will be used.
>>>> This majority vote stays open for 72 hours.
>>>> Please cast your votes.
>>>> Here is my +1
>>>
>>> During the voting period there were 12 +1 votes and one negative
>>> one.
>> What about Alfred's -1 vote?
>
> During the voting period there were 12 +1 votes and one negative one.
> ^^^
Oops read it as 'no negative ones' - sorry :)
Vadim
Re: [summary][vote] Cocoon 3.0
Posted by Reinhard Pötz <re...@apache.org>.
Vadim Gritsenko wrote:
> On Aug 10, 2008, at 4:19 AM, Reinhard Pötz wrote:
>
>> Reinhard Pötz wrote:
>>> Following the result of our recent discussion about the future of
>>> Corona, I propose Corona to become Cocoon 3.
>>> This means that any reference on Corona in source files, package
>>> names, artifact ids, group ids or anywhere else will be dropped and
>>> the standard Cocoon namespace org.apache.cocoon will be used.
>>> This majority vote stays open for 72 hours.
>>> Please cast your votes.
>>> Here is my +1
>>
>> During the voting period there were 12 +1 votes and one negative one.
>
> What about Alfred's -1 vote?
During the voting period there were 12 +1 votes and one negative one.
^^^
--
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
________________________________________________________________________
Re: [summary][vote] Cocoon 3.0
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 10, 2008, at 4:19 AM, Reinhard Pötz wrote:
> Reinhard Pötz wrote:
>> Following the result of our recent discussion about the future of
>> Corona, I propose Corona to become Cocoon 3.
>> This means that any reference on Corona in source files, package
>> names, artifact ids, group ids or anywhere else will be dropped and
>> the standard Cocoon namespace org.apache.cocoon will be used.
>> This majority vote stays open for 72 hours.
>> Please cast your votes.
>> Here is my +1
>
> During the voting period there were 12 +1 votes and one negative one.
What about Alfred's -1 vote?
Vadim
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Rainer Pruy <Ra...@Acrys.COM>.
Just another 0.01€ in the same direction:
most "developing" users (esp. the ones developing cocoon itself) would qualify as hackers.
Those are used to associate special meanings with groups of version numbers
as a number of other projects follow similar rules (e.g. Linux for long used that even/odd numbering scheme).
However, as Cocoon will (and should) attract non hacker users,
on a first view, what will indicate to them, that version 3.1.2 is not "superior" to 3.0.9?
(superior aka later or more mature)
While I personally am quite fine with any versioning scheme,
I do think, it is absolutely necessary to have a policy document explaining it
to accidental users. And this nearly at the same time they will detect something like cocoon does exist at all.
Rainer
Sylvain Wallez schrieb:
> Reinhard Pötz wrote:
>
>> Versioning
>> -------------------------------
>> For Cocoon 2 there have been proposals that all odd versions are
>> development/alpha versions and all even versions are stable releases.
>>
>> I like this idea and propose that we follow this versioning schema in
>> Cocoon 3: All 3.0.x releases are marked as development versions and we
>> clearly explain this on the website and the READMEs of all artifacts.
>>
>> When we believe that the community and the technology are stable, we do
>> a 3.1.0 release.
>>
>> I think this is less confusing than appending alpha, beta or milestone
>> postfixes.
>>
>
> I would say the contrary. Let's not forget that most of our users aren't
> hard-core developers (they love Cocoon because they can do complex stuff
> without programming) and they aren't used to this odd/even versioning
> scheme that comes from the Linux kernel.
>
> Rather than that, it seems to me that most of the "normal" (i.e. non
> hard-core hacker) people consider a version without any "beta",
> "milestone" or other suffix as an official stable release. A well-known
> example is Firefox that goes through a series of milestones, beta and RC
> version before releasing a stable version with the same number. Eclipse
> does the same.
>
> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
> vacation, but I really think this is too early. Cocoon 2.2 is just out
> and we announce a 3.0. This will most probably lead people to consider
> 2.2 as a transition to 3.0 and just not use it, and thus just look
> elsewhere. Stated clearly, I have fears that just as Maven almost killed
> the developer community for 2.2, announcing a 3.0 now will kill the user
> community.
>
> My 0.02 euros.
>
> Sylvain
>
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Sylvain Wallez wrote:
>> Reinhard Pötz wrote:
>>> Sylvain Wallez wrote:
>>>
>>>> Reinhard Pötz wrote:
>>>>
>>>>
>>>>> Versioning
>>>>> -------------------------------
>>>>> For Cocoon 2 there have been proposals that all odd versions are
>>>>> development/alpha versions and all even versions are stable releases.
>>>>>
>>>>> I like this idea and propose that we follow this versioning schema in
>>>>> Cocoon 3: All 3.0.x releases are marked as development versions and we
>>>>> clearly explain this on the website and the READMEs of all artifacts.
>>>>>
>>>>> When we believe that the community and the technology are stable, we do
>>>>> a 3.1.0 release.
>>>>>
>>>>> I think this is less confusing than appending alpha, beta or milestone
>>>>> postfixes.
>>>>>
>>>> I would say the contrary. Let's not forget that most of our users aren't
>>>> hard-core developers (they love Cocoon because they can do complex stuff
>>>> without programming) and they aren't used to this odd/even versioning
>>>> scheme that comes from the Linux kernel.
>>>>
>>>> Rather than that, it seems to me that most of the "normal" (i.e. non
>>>> hard-core hacker) people consider a version without any "beta",
>>>> "milestone" or other suffix as an official stable release. A well-known
>>>> example is Firefox that goes through a series of milestones, beta and RC
>>>> version before releasing a stable version with the same number. Eclipse
>>>> does the same.
>>>>
>>> I don't have a strong opinion on this, except that I don't think that
>>> the term milestone doesn't fit very well for us because this would imply
>>> that we have like e.g. Eclipse a well-defined roadmap. And as we all
>>> know, that's simply not the case.
>>>
>> Well, although there's no formal roadmaps, there are "big features" that
>> more or less define it, isn't it?
>>
>>> I'm also fine with 3.0-alpha-1, etc. and, see the reasons below, it's
>>> probably better to change the proposal into this direction.
>>>
>>>> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
>>>> vacation, but I really think this is too early. Cocoon 2.2 is just out
>>>> and we announce a 3.0. This will most probably lead people to consider
>>>> 2.2 as a transition to 3.0 and just not use it, and thus just look
>>>> elsewhere. Stated clearly, I have fears that just as Maven almost killed
>>>> the developer community for 2.2, announcing a 3.0 now will kill the user
>>>> community.
>>>>
>>> We had three possible routes for Corona:
>>>
>>> 1) Develop Corona outside of the Cocoon project (e.g. Google,
>>> Sourceforge, etc.)
>>> 2) Find some alternative name and release it under this codename.
>>> 3) Release it as Cocoon 3.0-alpha-x
>>>
>>> 1) would have been really dangerous IMO. What would people have thought
>>> if the former PMC chair created an alternative project that is a
>>> reimplementation of Cocoon outside of the oversight of the Cocoon PMC.
>>> And that just a few months after his resignation.
>>>
>> I totally agree with this, and Apache has the necessary rules and
>> infrastructure to host experiments/rewrites/revolutions under the
>> project's umbrella.
>>
>>> 2) Many people advised not to invent another codename. Also the name
>>> finding game wasn't really successful. Personally I'm not willing to
>>> invest any more time into this.
>>>
>> I don't think there's even a need to play the name game: if the
>> experiment/rewrite/revolution is successful, it just takes over the main
>> branch (e.g. Catalina that has replaced Tomcat) and otherwise it just
>> dies and vanishes.
>>
>>> 3) Releasing 3.0 comes with the risk that 3.0 never takes off and
>>> doesn't attract a broader developer and user community. But as long as
>>> we only release alpha software, we can even do a re-rewrite.
>>>
>> Not sure I follow you here, and how 3.0 or any other name prevents a
>> rewrite as long as there hasn't been any stable release. Now if there is
>> an ongoing effort on something named "3.0" and suddenly this thing is
>> rewritten, this is likely to be interpreted by the community as "we
>> don't really know where we're going" which not a good thing.
>>
>>> Regarding your "too early announced" argument, I'm not so pessimistic.
>>> Most people very well understand the difference between production
>>> quality and alpha software and that alpha software is no guarantee for
>>> anything (time, quality/stability, community). Addtionally we will add
>>> warnings to all download pages, READMEs and also adding "alpha" helps.
>>>
>>> Also other projects demonstrate that having an alpha branch doesn't make
>>> most people wait for the final release of the alpha branch (see Tomcat,
>>> Jetty, Maven, httpd, etc.). And if you have time to wait, I don't think
>>> that you really have to solve a problem.
>>>
>> I hope you're right.
>
> As I wrote on my blog, I think that Cocoon has to change fundamentally
> (focus on RESTful services, layered architecture and reuse in every Java
> environment) in order to survive in the medium to long term. Staying
> with Cocoon 2.x will mostly please already existing users but won't be
> very attractive for others.
>
> I wasn't very eager to go for Cocoon 3 at this point of time myself.
> Cocoon 3 has been developed completely in the spare time of volunteers
> and releasing it will put some pressure on it that I would have liked to
> avoid it.
I meant "releasing it as 'Cocoon 3'' will put ...
> But keeping it in the whiteboard without a release isn't a solution as well.
>
> Cocoon 3 is a chance without a guarantee of success. But it's better
> than just waiting for some kind of miracle and doing nothing while
> Cocoon and its community are fading away.
--
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
________________________________________________________________________
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
>
> As I wrote on my blog, I think that Cocoon has to change fundamentally
> (focus on RESTful services, layered architecture and reuse in every Java
> environment) in order to survive in the medium to long term. Staying
> with Cocoon 2.x will mostly please already existing users but won't be
> very attractive for others.
>
> I wasn't very eager to go for Cocoon 3 at this point of time myself.
> Cocoon 3 has been developed completely in the spare time of volunteers
> and releasing it will put some pressure on it that I would have liked to
> avoid it.
> But keeping it in the whiteboard without a release isn't a solution as well.
>
> Cocoon 3 is a chance without a guarantee of success. But it's better
> than just waiting for some kind of miracle and doing nothing while
> Cocoon and its community are fading away.
Even if I'm still busy with supporting community with 2.2 transition so I have no time to work on
Corona/3.0 I wholeheartedly support Reinhard's position.
--
Best regards,
Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Reinhard Pötz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Pötz wrote:
>> Sylvain Wallez wrote:
>>
>>> Reinhard Pötz wrote:
>>>
>>>
>>>> Versioning
>>>> -------------------------------
>>>> For Cocoon 2 there have been proposals that all odd versions are
>>>> development/alpha versions and all even versions are stable releases.
>>>>
>>>> I like this idea and propose that we follow this versioning schema in
>>>> Cocoon 3: All 3.0.x releases are marked as development versions and we
>>>> clearly explain this on the website and the READMEs of all artifacts.
>>>>
>>>> When we believe that the community and the technology are stable, we do
>>>> a 3.1.0 release.
>>>>
>>>> I think this is less confusing than appending alpha, beta or milestone
>>>> postfixes.
>>>>
>>> I would say the contrary. Let's not forget that most of our users aren't
>>> hard-core developers (they love Cocoon because they can do complex stuff
>>> without programming) and they aren't used to this odd/even versioning
>>> scheme that comes from the Linux kernel.
>>>
>>> Rather than that, it seems to me that most of the "normal" (i.e. non
>>> hard-core hacker) people consider a version without any "beta",
>>> "milestone" or other suffix as an official stable release. A well-known
>>> example is Firefox that goes through a series of milestones, beta and RC
>>> version before releasing a stable version with the same number. Eclipse
>>> does the same.
>>>
>>
>> I don't have a strong opinion on this, except that I don't think that
>> the term milestone doesn't fit very well for us because this would imply
>> that we have like e.g. Eclipse a well-defined roadmap. And as we all
>> know, that's simply not the case.
>>
>
> Well, although there's no formal roadmaps, there are "big features" that
> more or less define it, isn't it?
>
>> I'm also fine with 3.0-alpha-1, etc. and, see the reasons below, it's
>> probably better to change the proposal into this direction.
>>
>>> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
>>> vacation, but I really think this is too early. Cocoon 2.2 is just out
>>> and we announce a 3.0. This will most probably lead people to consider
>>> 2.2 as a transition to 3.0 and just not use it, and thus just look
>>> elsewhere. Stated clearly, I have fears that just as Maven almost killed
>>> the developer community for 2.2, announcing a 3.0 now will kill the user
>>> community.
>>>
>>
>> We had three possible routes for Corona:
>>
>> 1) Develop Corona outside of the Cocoon project (e.g. Google,
>> Sourceforge, etc.)
>> 2) Find some alternative name and release it under this codename.
>> 3) Release it as Cocoon 3.0-alpha-x
>>
>> 1) would have been really dangerous IMO. What would people have thought
>> if the former PMC chair created an alternative project that is a
>> reimplementation of Cocoon outside of the oversight of the Cocoon PMC.
>> And that just a few months after his resignation.
>>
>
> I totally agree with this, and Apache has the necessary rules and
> infrastructure to host experiments/rewrites/revolutions under the
> project's umbrella.
>
>> 2) Many people advised not to invent another codename. Also the name
>> finding game wasn't really successful. Personally I'm not willing to
>> invest any more time into this.
>>
>
> I don't think there's even a need to play the name game: if the
> experiment/rewrite/revolution is successful, it just takes over the main
> branch (e.g. Catalina that has replaced Tomcat) and otherwise it just
> dies and vanishes.
>
>> 3) Releasing 3.0 comes with the risk that 3.0 never takes off and
>> doesn't attract a broader developer and user community. But as long as
>> we only release alpha software, we can even do a re-rewrite.
>>
>
> Not sure I follow you here, and how 3.0 or any other name prevents a
> rewrite as long as there hasn't been any stable release. Now if there is
> an ongoing effort on something named "3.0" and suddenly this thing is
> rewritten, this is likely to be interpreted by the community as "we
> don't really know where we're going" which not a good thing.
>
>> Regarding your "too early announced" argument, I'm not so pessimistic.
>> Most people very well understand the difference between production
>> quality and alpha software and that alpha software is no guarantee for
>> anything (time, quality/stability, community). Addtionally we will add
>> warnings to all download pages, READMEs and also adding "alpha" helps.
>>
>> Also other projects demonstrate that having an alpha branch doesn't make
>> most people wait for the final release of the alpha branch (see Tomcat,
>> Jetty, Maven, httpd, etc.). And if you have time to wait, I don't think
>> that you really have to solve a problem.
>>
>
> I hope you're right.
As I wrote on my blog, I think that Cocoon has to change fundamentally
(focus on RESTful services, layered architecture and reuse in every Java
environment) in order to survive in the medium to long term. Staying
with Cocoon 2.x will mostly please already existing users but won't be
very attractive for others.
I wasn't very eager to go for Cocoon 3 at this point of time myself.
Cocoon 3 has been developed completely in the spare time of volunteers
and releasing it will put some pressure on it that I would have liked to
avoid it.
But keeping it in the whiteboard without a release isn't a solution as well.
Cocoon 3 is a chance without a guarantee of success. But it's better
than just waiting for some kind of miracle and doing nothing while
Cocoon and its community are fading away.
--
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
________________________________________________________________________
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Pötz wrote:
> Sylvain Wallez wrote:
>
>> Reinhard Pötz wrote:
>>
>>
>>> Versioning
>>> -------------------------------
>>> For Cocoon 2 there have been proposals that all odd versions are
>>> development/alpha versions and all even versions are stable releases.
>>>
>>> I like this idea and propose that we follow this versioning schema in
>>> Cocoon 3: All 3.0.x releases are marked as development versions and we
>>> clearly explain this on the website and the READMEs of all artifacts.
>>>
>>> When we believe that the community and the technology are stable, we do
>>> a 3.1.0 release.
>>>
>>> I think this is less confusing than appending alpha, beta or milestone
>>> postfixes.
>>>
>>>
>> I would say the contrary. Let's not forget that most of our users aren't
>> hard-core developers (they love Cocoon because they can do complex stuff
>> without programming) and they aren't used to this odd/even versioning
>> scheme that comes from the Linux kernel.
>>
>> Rather than that, it seems to me that most of the "normal" (i.e. non
>> hard-core hacker) people consider a version without any "beta",
>> "milestone" or other suffix as an official stable release. A well-known
>> example is Firefox that goes through a series of milestones, beta and RC
>> version before releasing a stable version with the same number. Eclipse
>> does the same.
>>
>
> I don't have a strong opinion on this, except that I don't think that
> the term milestone doesn't fit very well for us because this would imply
> that we have like e.g. Eclipse a well-defined roadmap. And as we all
> know, that's simply not the case.
>
Well, although there's no formal roadmaps, there are "big features" that
more or less define it, isn't it?
> I'm also fine with 3.0-alpha-1, etc. and, see the reasons below, it's
> probably better to change the proposal into this direction.
>
>> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
>> vacation, but I really think this is too early. Cocoon 2.2 is just out
>> and we announce a 3.0. This will most probably lead people to consider
>> 2.2 as a transition to 3.0 and just not use it, and thus just look
>> elsewhere. Stated clearly, I have fears that just as Maven almost killed
>> the developer community for 2.2, announcing a 3.0 now will kill the user
>> community.
>>
>
> We had three possible routes for Corona:
>
> 1) Develop Corona outside of the Cocoon project (e.g. Google,
> Sourceforge, etc.)
> 2) Find some alternative name and release it under this codename.
> 3) Release it as Cocoon 3.0-alpha-x
>
> 1) would have been really dangerous IMO. What would people have thought
> if the former PMC chair created an alternative project that is a
> reimplementation of Cocoon outside of the oversight of the Cocoon PMC.
> And that just a few months after his resignation.
>
I totally agree with this, and Apache has the necessary rules and
infrastructure to host experiments/rewrites/revolutions under the
project's umbrella.
> 2) Many people advised not to invent another codename. Also the name
> finding game wasn't really successful. Personally I'm not willing to
> invest any more time into this.
>
I don't think there's even a need to play the name game: if the
experiment/rewrite/revolution is successful, it just takes over the main
branch (e.g. Catalina that has replaced Tomcat) and otherwise it just
dies and vanishes.
> 3) Releasing 3.0 comes with the risk that 3.0 never takes off and
> doesn't attract a broader developer and user community. But as long as
> we only release alpha software, we can even do a re-rewrite.
>
Not sure I follow you here, and how 3.0 or any other name prevents a
rewrite as long as there hasn't been any stable release. Now if there is
an ongoing effort on something named "3.0" and suddenly this thing is
rewritten, this is likely to be interpreted by the community as "we
don't really know where we're going" which not a good thing.
> Regarding your "too early announced" argument, I'm not so pessimistic.
> Most people very well understand the difference between production
> quality and alpha software and that alpha software is no guarantee for
> anything (time, quality/stability, community). Addtionally we will add
> warnings to all download pages, READMEs and also adding "alpha" helps.
>
> Also other projects demonstrate that having an alpha branch doesn't make
> most people wait for the final release of the alpha branch (see Tomcat,
> Jetty, Maven, httpd, etc.). And if you have time to wait, I don't think
> that you really have to solve a problem.
>
I hope you're right.
> Additionally we have taken care that Cocoon 2.2 can be run in parallel
> with Cocoon 3.0 in the same web application and they can event
> communicate via the Servlet-Service framework with each other.
>
Great!
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Reinhard Pötz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Pötz wrote:
>
>> Versioning
>> -------------------------------
>> For Cocoon 2 there have been proposals that all odd versions are
>> development/alpha versions and all even versions are stable releases.
>>
>> I like this idea and propose that we follow this versioning schema in
>> Cocoon 3: All 3.0.x releases are marked as development versions and we
>> clearly explain this on the website and the READMEs of all artifacts.
>>
>> When we believe that the community and the technology are stable, we do
>> a 3.1.0 release.
>>
>> I think this is less confusing than appending alpha, beta or milestone
>> postfixes.
>>
>
> I would say the contrary. Let's not forget that most of our users aren't
> hard-core developers (they love Cocoon because they can do complex stuff
> without programming) and they aren't used to this odd/even versioning
> scheme that comes from the Linux kernel.
>
> Rather than that, it seems to me that most of the "normal" (i.e. non
> hard-core hacker) people consider a version without any "beta",
> "milestone" or other suffix as an official stable release. A well-known
> example is Firefox that goes through a series of milestones, beta and RC
> version before releasing a stable version with the same number. Eclipse
> does the same.
I don't have a strong opinion on this, except that I don't think that
the term milestone doesn't fit very well for us because this would imply
that we have like e.g. Eclipse a well-defined roadmap. And as we all
know, that's simply not the case.
I'm also fine with 3.0-alpha-1, etc. and, see the reasons below, it's
probably better to change the proposal into this direction.
> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
> vacation, but I really think this is too early. Cocoon 2.2 is just out
> and we announce a 3.0. This will most probably lead people to consider
> 2.2 as a transition to 3.0 and just not use it, and thus just look
> elsewhere. Stated clearly, I have fears that just as Maven almost killed
> the developer community for 2.2, announcing a 3.0 now will kill the user
> community.
We had three possible routes for Corona:
1) Develop Corona outside of the Cocoon project (e.g. Google,
Sourceforge, etc.)
2) Find some alternative name and release it under this codename.
3) Release it as Cocoon 3.0-alpha-x
1) would have been really dangerous IMO. What would people have thought
if the former PMC chair created an alternative project that is a
reimplementation of Cocoon outside of the oversight of the Cocoon PMC.
And that just a few months after his resignation.
2) Many people advised not to invent another codename. Also the name
finding game wasn't really successful. Personally I'm not willing to
invest any more time into this.
3) Releasing 3.0 comes with the risk that 3.0 never takes off and
doesn't attract a broader developer and user community. But as long as
we only release alpha software, we can even do a re-rewrite.
Regarding your "too early announced" argument, I'm not so pessimistic.
Most people very well understand the difference between production
quality and alpha software and that alpha software is no guarantee for
anything (time, quality/stability, community). Addtionally we will add
warnings to all download pages, READMEs and also adding "alpha" helps.
Also other projects demonstrate that having an alpha branch doesn't make
most people wait for the final release of the alpha branch (see Tomcat,
Jetty, Maven, httpd, etc.). And if you have time to wait, I don't think
that you really have to solve a problem.
Additionally we have taken care that Cocoon 2.2 can be run in parallel
with Cocoon 3.0 in the same web application and they can event
communicate via the Servlet-Service framework with each other.
--
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
________________________________________________________________________
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Posted by Jeremy Quinn <je...@apache.org>.
Just an added note ....
On 19 Aug 2008, at 16:04, Jeremy Quinn wrote:
> It would be typical to assume (IMHO) that 3.0 is somehow better than
> 2.2 which is somehow better than 2.1, just because of the version
> numbers.
This assumption is so easy to make, because for instance :
2.1 was better than 2.0 which was MUCH better than 1.0 etc.
But now, we seem to use version numbers differently.
regards Jeremy
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Posted by Jeremy Quinn <je...@apache.org>.
Hi Grzegorz,
Many thanks for your response : )
On 19 Aug 2008, at 12:54, Grzegorz Kossakowski wrote:
> Hi Jeremy,
>
> Jeremy Quinn pisze:
>> From the PoV of users, it should also be clear :
>> If you want or have to use Ant, use 2.1
>> If you want or have to use Maven, use 2.2
>> If you just need the Pipeline API, use 3.0
>
> I'm not sure if I get you here correctly so I'll ask:
> Do you express your own wish or your own perception of situation we
> have when it comes to differences between 2.1 and 2.2?
I am trying to think about this from a 'marketing' perspective.
It would be typical to assume (IMHO) that 3.0 is somehow better than
2.2 which is somehow better than 2.1, just because of the version
numbers.
Whereas from the point of view of a User, making projects (using
SiteMaps, XML, XSLT, JXTemplate, FlowScript, etc. etc.) 2.1 and 2.2
are as much as possible, completely compatible and mostly just as
capable as each other.
The fact that once a User has a suitable build, it makes very little
difference whether they use 2.1 or 2.2 (not sure about 3.0) is
something that I think we should put across more clearly.
It would be a shame to loose potential Users, because they perceived
that the version that used their preferred build-technology, was in
some way obsolete (which could now happen with both 2.1 and 2.2).
Maybe a capability matrix of some sort, would help a User trying to
decide which version to use, would provide more reassurance that the 3
versions (or at least 2.1 and 2.2) would provide a viable, stable,
long-lasting platform, even though the version numbers may say
otherwise.
>> There should be no other difference in quality between the release
>> versions, and none should be implied.
>
> I'm afraid that it's not a case for some time at least according to
> my understand of Cocoon 2.2.
The build and distribution system for 2.2 is clearly more modern and
sophisticated.
It has a polymorphic block paradigm that suits the build technology,
it has the powerful concept of virtual pipelines etc. etc.
And this is all great !
But from the Users' PoV of making projects, I cannot imagine a project
that could be made successfully with 2.2 that could not be made using
2.1 (don't know enough about 3.0).
My assumption is that you personally find 2.2 more powerful because
you prefer the build technology, not because 2.2 is intrinsically more
powerful, or less buggy.
This is why I propose that we should give a clear message that all
release versions are valid choices, primarily dependant on the build-
technology that you prefer, not on specific version numbers.
AFAIU, TomCat is in a similar situation, where the different primary
versions, represent not quality, but the version of the ServletAPI and
JSP Spec they support.
see: http://tomcat.apache.org/whichversion.html
I hope this is clearer
best regards
Jeremy
Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona
to Cocoon 3.0 and infrastructure)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Hi Jeremy,
Jeremy Quinn pisze:
> From the PoV of users, it should also be clear :
>
> If you want or have to use Ant, use 2.1
> If you want or have to use Maven, use 2.2
> If you just need the Pipeline API, use 3.0
I'm not sure if I get you here correctly so I'll ask:
Do you express your own wish or your own perception of situation we have when it comes to
differences between 2.1 and 2.2?
> There should be no other difference in quality between the release
> versions, and none should be implied.
I'm afraid that it's not a case for some time at least according to my understand of Cocoon 2.2.
--
Best regards,
Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Jeremy Quinn <je...@apache.org>.
Hi Carsten
On 18 Aug 2008, at 16:41, Carsten Ziegeler wrote:
> Please, let's not get into the usual maven bashing threads. I'm
> tired of
> reading all the love and hate about maven over and over again.
>
> If someone thinks that the current system sucks *and* has time to try
> out new things, great. If not, let's keep the working system.
I agree 100% and apologise if I helped raise it again .....
What you stated, I think is the correct PoV for Cocoon developers.
From the PoV of users, it should also be clear :
If you want or have to use Ant, use 2.1
If you want or have to use Maven, use 2.2
If you just need the Pipeline API, use 3.0
There should be no other difference in quality between the release
versions, and none should be implied.
best regards
Jeremy
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Carsten Ziegeler <cz...@apache.org>.
Please, let's not get into the usual maven bashing threads. I'm tired of
reading all the love and hate about maven over and over again.
If someone thinks that the current system sucks *and* has time to try
out new things, great. If not, let's keep the working system.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>>
>> By "chronic disease", I was referring to Maven. And it's not specific
>> to Cocoon, but to many other projects. Maven has brought one new
>> brillant idea to the Java world, which is artifact repositories (note
>> though that Linux repositories have existed for a very long time).
>> But using Maven requires to adhere to the whole thing: repository
>> management, which is good, but also a declarative under-documented
>> build system. And Maven is also self-updating, which is a nice idea
>> on paper but means the buid is not repeatable since you don't know
>> what is used to build your system.
> Wow. I guess you don't like Maven.
>
> There are other alternatives to your complaints - like becoming a
> committer there and fixing them.
That is exactly what I wanted to point out with the "Maven sucked too
much energy from Cocoon" argument: I don't want and shouldn't have to
become a committer on the build system as a necessary preliminary to
doing usefull stuff on Cocoon.
> Using Ant + Ivy has all the downfalls of GNU Make. Instead of one
> "undocumented" (not sure where you get that from) build system you end
> up with every build system being different and usually, mostly
> undocumented.
Most of the Maven plugins can be rewritten in a couple of Ant lines.
Also, it is possible to have common reusable Ant build files that avoid
rewriting everything from scratch every time. Now it's true that no
community effort has taken place to provide a distribution of such
standard reusable Ant files. Maybe people did not felt the urge to do so
because Ant files to build simple artifacts are so straightforward.
> As for the self-updating, dependency management allows you to have
> complete control over the artifacts you wish to use. My contribution
> to Maven has to continue to make that aspect better.
I now this is work in progress. But not self-updating should be the
default rather than being an intial feature that can be disabled by
specifying the exact version of each and every Maven plugin you want a
fixed-version of (and how do I know which version I want?)
Now I'll shut up since most people here seem to be happy with Maven. I'm
not, let's move on to other debates.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
>
> By "chronic disease", I was referring to Maven. And it's not specific
> to Cocoon, but to many other projects. Maven has brought one new
> brillant idea to the Java world, which is artifact repositories (note
> though that Linux repositories have existed for a very long time). But
> using Maven requires to adhere to the whole thing: repository
> management, which is good, but also a declarative under-documented
> build system. And Maven is also self-updating, which is a nice idea on
> paper but means the buid is not repeatable since you don't know what
> is used to build your system.
Wow. I guess you don't like Maven.
There are other alternatives to your complaints - like becoming a
committer there and fixing them. Using Ant + Ivy has all the downfalls
of GNU Make. Instead of one "undocumented" (not sure where you get that
from) build system you end up with every build system being different
and usually, mostly undocumented.
As for the self-updating, dependency management allows you to have
complete control over the artifacts you wish to use. My contribution to
Maven has to continue to make that aspect better.
Ralph
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Sylvain Wallez <sy...@apache.org>.
Grzegorz Kossakowski wrote:
> Sylvain Wallez pisze:
>> I can't say what problems there are _now_ since I don't build Cocoon
>> anymore. Hopefully it works now, and I was referring to the past:
>> when the move to Maven was started, the 2.2 build was mostly broken
>> for months, which drained an incredible amount of energy away from
>> the project, either because people got discouraged by this broken
>> build (e.g. me), or because they invested their volunteer time in
>> understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon.
>>
>> I'm glad it seems to work now, but the amount of energy needed to
>> setup and maintain this build system (remember, it's _just_ a build
>> system) has been astronomical.
>
> I've been working with Maven (mainly when working with Cocoon) for
> more than year and I can agree on main point of Maven critics that
> Maven is flawed.
> My personal opinion is that basic ideas behind Maven are correct but
> implementation is totally broken. Or at least it was at the beginning
> because now, thanks to many eye balls, it seems to improve from
> release to release.
>
> I was wondering many times if there is any other choice for us. Given
> the amount energy we've put into mavenization process any switch is
> impossible so such discussion could be only theoretical. Still I would
> enjoy reading about some alternatives because this could put my (and
> probably others) thinking into right direction thus, eventually
> improving our existing infrastructure.
This isn't theoretical at all. Use Ant+Ivy (http://ant.apache.org/ivy/)
and you have something that doesn't rely on undocumented declarative
black magic (the various plugins you add to your pom.xml), doesn't
require you to write your own plugins (or tasks as they're called in
Ant) and gives you line-precise error reporting when something goes wrong.
> There is one statement that I don't agree: Maven is not just a build
> system. If it was only a build system I would be the first one to
> propose dropping Maven completely because of its implementation. For
> me, Maven is the whole ecosystem which consists of good practices when
> it comes to your project's structure, Maven repository (the killer
> feature IMHO) and integration with so many systems acting around basic
> build process.
Ivy for your artifacts management. It does it well, and can use Maven
repositories. I've been using it happily for more than 2 years now on
rather big projects (after having banged my head on Maven).
> What I would prefer is to take a lesson from our past experience but
> still focus on the future. I strongly believe that we have reached
> this stage when people can happily focus on developing Cocoon and not
> on developing Cocoon's infrastructure thus I would like to invite all
> old-timers to join our forces and provide the best of Cocoon
> experience ever. I strongly believe we have all foundations needed for
> that now.
And this leads to another question, which Reinhard outlined in his
latest blog post, and Stefano did years ago: what's the purpose of
Cocoon in today's technology landscape? It used to be a great "you can
do everything with it" solution, but these days are over. There are some
very nice webapp component frameworks like Wicket or GWT, there are ESBs
that do pipelined transformations like Mule or ServiceMix, and XML is no
more the only mainstream interchange language with the success of JSON
and the emergence of binary formats like Thrift or Google Buffers.
Cocoon therefore has to be rethought as a toolbox for those domains
where it has no equivalent, and find new domains where it can innovate,
and Corona (or whatever its name) certainly goes in the right direction.
Pipelines are among the existing distinctive features of Cocoon, and
also REST-ish pattern matching although many frameworks are now
REST-friendly.
>> It's very nice to see people using 2.2, but I have the impression
>> that most of the 2.2-related questions are related to maven-isms,
>> artifacts, poms, etc. Without wanting to sound harsh, I'm wondering
>> whether this community has learned to live over time with some sort
>> of chronic disease, and is so used to it now that it doesn't even
>> realize that life could be easier without it.
>
> Most of these questions come from the confusion about splitting up
> Cocoon into smaller pieces. And even more questions come from the fact
> that people starting with 2.2 are still trying to build it themselves
> because that was done in 2.1. If you use released versions then you
> will have no problem with dependencies, missing artifacts, etc.
> When you checkout trunk and try to build it then I would say that it
> should be no surprise that sometimes you get into troubles, right?
The build should fail only if there are some bugs in Cocoon's code
(compilation issues or failed tests) or if some artifacts are missing
from your cache and remote repositories aren't available (BTW this what
just happened to me: there's a compilation failure in cocoon-core).
> I would really like to know what kind of chronic disease you see
> Sylvain. I don't deny there might be one so if you would have shared
> your observations with rest community we could start to think about
> improving it in the future.
By "chronic disease", I was referring to Maven. And it's not specific to
Cocoon, but to many other projects. Maven has brought one new brillant
idea to the Java world, which is artifact repositories (note though that
Linux repositories have existed for a very long time). But using Maven
requires to adhere to the whole thing: repository management, which is
good, but also a declarative under-documented build system. And Maven is
also self-updating, which is a nice idea on paper but means the buid is
not repeatable since you don't know what is used to build your system.
This works very well for small projects that have few dependencies and
produce only few standard artifacts like jar files, and this explains
its success in the opensource community where it is very often in this
case, and also why it has been so painful for Cocoon which is a quite
complex beast.
>> Note that I said "could" and not "would" since ultimately the
>> people-that-do decide what they prefer. And yes I'm a retired
>> old-timer here, but I still care for this community where I learned
>> so much.
>
> For me it would be interesting to see if one of "retired old-timers"
> could try to spend some time on playing with trunk just to gather some
> experience. Certainly, such "external" audit by some of the most
> honored members of this community would be a blessing experience only
> if it would allow to bring closer our stances.
I'm afraid I don't have the free cycles for this.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Sylvain Wallez pisze:
> I can't say what problems there are _now_ since I don't build Cocoon
> anymore. Hopefully it works now, and I was referring to the past: when
> the move to Maven was started, the 2.2 build was mostly broken for
> months, which drained an incredible amount of energy away from the
> project, either because people got discouraged by this broken build
> (e.g. me), or because they invested their volunteer time in
> understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon.
>
> I'm glad it seems to work now, but the amount of energy needed to setup
> and maintain this build system (remember, it's _just_ a build system)
> has been astronomical.
I've been working with Maven (mainly when working with Cocoon) for more than year and I can agree on
main point of Maven critics that Maven is flawed.
My personal opinion is that basic ideas behind Maven are correct but implementation is totally
broken. Or at least it was at the beginning because now, thanks to many eye balls, it seems to
improve from release to release.
I was wondering many times if there is any other choice for us. Given the amount energy we've put
into mavenization process any switch is impossible so such discussion could be only theoretical.
Still I would enjoy reading about some alternatives because this could put my (and probably others)
thinking into right direction thus, eventually improving our existing infrastructure.
There is one statement that I don't agree: Maven is not just a build system. If it was only a build
system I would be the first one to propose dropping Maven completely because of its implementation.
For me, Maven is the whole ecosystem which consists of good practices when it comes to your
project's structure, Maven repository (the killer feature IMHO) and integration with so many systems
acting around basic build process.
What I would prefer is to take a lesson from our past experience but still focus on the future. I
strongly believe that we have reached this stage when people can happily focus on developing Cocoon
and not on developing Cocoon's infrastructure thus I would like to invite all old-timers to join our
forces and provide the best of Cocoon experience ever. I strongly believe we have all foundations
needed for that now.
> It's very nice to see people using 2.2, but I have the impression that
> most of the 2.2-related questions are related to maven-isms, artifacts,
> poms, etc. Without wanting to sound harsh, I'm wondering whether this
> community has learned to live over time with some sort of chronic
> disease, and is so used to it now that it doesn't even realize that life
> could be easier without it.
Most of these questions come from the confusion about splitting up Cocoon into smaller pieces. And
even more questions come from the fact that people starting with 2.2 are still trying to build it
themselves because that was done in 2.1. If you use released versions then you will have no problem
with dependencies, missing artifacts, etc.
When you checkout trunk and try to build it then I would say that it should be no surprise that
sometimes you get into troubles, right?
I would really like to know what kind of chronic disease you see Sylvain. I don't deny there might
be one so if you would have shared your observations with rest community we could start to think
about improving it in the future.
> Note that I said "could" and not "would" since ultimately the
> people-that-do decide what they prefer. And yes I'm a retired old-timer
> here, but I still care for this community where I learned so much.
For me it would be interesting to see if one of "retired old-timers" could try to spend some time on
playing with trunk just to gather some experience. Certainly, such "external" audit by some of the
most honored members of this community would be a blessing experience only if it would allow to
bring closer our stances.
--
Best regards,
Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Sylvain Wallez <sy...@apache.org>.
Grzegorz Kossakowski wrote:
> Sylvain Wallez pisze:
>>
>> I would say the contrary. Let's not forget that most of our users
>> aren't hard-core developers (they love Cocoon because they can do
>> complex stuff without programming) and they aren't used to this
>> odd/even versioning scheme that comes from the Linux kernel.
>>
>> Rather than that, it seems to me that most of the "normal" (i.e. non
>> hard-core hacker) people consider a version without any "beta",
>> "milestone" or other suffix as an official stable release. A
>> well-known example is Firefox that goes through a series of
>> milestones, beta and RC version before releasing a stable version
>> with the same number. Eclipse does the same.
>
> Yes, that makes sense. I also wonder how beta, RC, etc. releases can
> be more confusing that odd/even versioning.
>
>> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was
>> on vacation, but I really think this is too early. Cocoon 2.2 is just
>> out and we announce a 3.0. This will most probably lead people to
>> consider 2.2 as a transition to 3.0 and just not use it, and thus
>> just look elsewhere.
>
> Provided that one documents our thoughts on 2.2 and 3.0 clearly I
> don't think there will be that much of confusion.
>
> Actually, I think it's a high time for us to define official document
> that explains our rules for giving artifacts version numbers. WDYT?
>
>> Stated clearly, I have fears that just as Maven almost killed the
>> developer community for 2.2, announcing a 3.0 now will kill the user
>> community.
>
> Sylvain, pardon my ignorance but what kind of real problems with Maven
> we have _now_ in Cocoon's trunk? I can understand that people were fed
> up with Maven at the beginning of the transition because it was almost
> impossible to build Cocoon. But that was more than one year ago.
I can't say what problems there are _now_ since I don't build Cocoon
anymore. Hopefully it works now, and I was referring to the past: when
the move to Maven was started, the 2.2 build was mostly broken for
months, which drained an incredible amount of energy away from the
project, either because people got discouraged by this broken build
(e.g. me), or because they invested their volunteer time in
understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon.
I'm glad it seems to work now, but the amount of energy needed to setup
and maintain this build system (remember, it's _just_ a build system)
has been astronomical.
> When it comes to user community, I would say that it grows quite
> nicely. There are people contributing[1][2] some tutorials, sharing
> their experience and seem to have a real fun with 2.2.
It's very nice to see people using 2.2, but I have the impression that
most of the 2.2-related questions are related to maven-isms, artifacts,
poms, etc. Without wanting to sound harsh, I'm wondering whether this
community has learned to live over time with some sort of chronic
disease, and is so used to it now that it doesn't even realize that life
could be easier without it.
Note that I said "could" and not "would" since ultimately the
people-that-do decide what they prefer. And yes I'm a retired old-timer
here, but I still care for this community where I learned so much.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Sylvain Wallez <sy...@apache.org>.
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>>> Stated clearly, I have fears that just as Maven almost killed the
>>> developer community for 2.2, announcing a 3.0 now will kill the user
>>> community.
>>
>> Sylvain, pardon my ignorance but what kind of real problems with
>> Maven we have _now_ in Cocoon's trunk? I can understand that people
>> were fed up with Maven at the beginning of the transition because it
>> was almost impossible to build Cocoon. But that was more than one
>> year ago.
>>
>> When it comes to user community, I would say that it grows quite
>> nicely. There are people contributing[1][2] some tutorials, sharing
>> their experience and seem to have a real fun with 2.2.
>>
>> Could it be a good idea that old-timers just take an example of our
>> user's community and overcome their own prejudices, finally?
>
> I realized that I little bit misunderstood Sylvain's e-mail and used
> inappropriate tone for my response. The last statement was not really
> needed.
>
> I'm sorry about that, Sylvain.
No worries. I was actually trying to understand what you really meant :-)
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Jeremy Quinn <je...@apache.org>.
Dear Grzegorz
I was just in the process of flaming the bejesus out of you for what
you just said!
Without a whole bunch of very smart 'old-timers' like Sylvain, there
would be no Cocoon.
The Ant versus Maven controversy has already caused too much
disaffection in this project, IMHO.
Thanks for retracting/apologising so quickly.
regards Jeremy
On 18 Aug 2008, at 11:05, Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>>> Stated clearly, I have fears that just as Maven almost killed the
>>> developer community for 2.2, announcing a 3.0 now will kill the
>>> user community.
>> Sylvain, pardon my ignorance but what kind of real problems with
>> Maven we have _now_ in Cocoon's trunk? I can understand that people
>> were fed up with Maven at the beginning of the transition because
>> it was almost impossible to build Cocoon. But that was more than
>> one year ago.
>> When it comes to user community, I would say that it grows quite
>> nicely. There are people contributing[1][2] some tutorials, sharing
>> their experience and seem to have a real fun with 2.2.
>> Could it be a good idea that old-timers just take an example of our
>> user's community and overcome their own prejudices, finally?
>
> I realized that I little bit misunderstood Sylvain's e-mail and used
> inappropriate tone for my response. The last statement was not
> really needed.
>
> I'm sorry about that, Sylvain.
>
> --
> Best regards,
> Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Grzegorz Kossakowski pisze:
>> Stated clearly, I have fears that just as Maven almost killed the
>> developer community for 2.2, announcing a 3.0 now will kill the user
>> community.
>
> Sylvain, pardon my ignorance but what kind of real problems with Maven
> we have _now_ in Cocoon's trunk? I can understand that people were fed
> up with Maven at the beginning of the transition because it was almost
> impossible to build Cocoon. But that was more than one year ago.
>
> When it comes to user community, I would say that it grows quite nicely.
> There are people contributing[1][2] some tutorials, sharing their
> experience and seem to have a real fun with 2.2.
>
> Could it be a good idea that old-timers just take an example of our
> user's community and overcome their own prejudices, finally?
I realized that I little bit misunderstood Sylvain's e-mail and used inappropriate tone for my
response. The last statement was not really needed.
I'm sorry about that, Sylvain.
--
Best regards,
Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Sylvain Wallez pisze:
>
> I would say the contrary. Let's not forget that most of our users aren't
> hard-core developers (they love Cocoon because they can do complex stuff
> without programming) and they aren't used to this odd/even versioning
> scheme that comes from the Linux kernel.
>
> Rather than that, it seems to me that most of the "normal" (i.e. non
> hard-core hacker) people consider a version without any "beta",
> "milestone" or other suffix as an official stable release. A well-known
> example is Firefox that goes through a series of milestones, beta and RC
> version before releasing a stable version with the same number. Eclipse
> does the same.
Yes, that makes sense. I also wonder how beta, RC, etc. releases can be more confusing that odd/even
versioning.
> Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
> vacation, but I really think this is too early. Cocoon 2.2 is just out
> and we announce a 3.0. This will most probably lead people to consider
> 2.2 as a transition to 3.0 and just not use it, and thus just look
> elsewhere.
Provided that one documents our thoughts on 2.2 and 3.0 clearly I don't think there will be that
much of confusion.
Actually, I think it's a high time for us to define official document that explains our rules for
giving artifacts version numbers. WDYT?
> Stated clearly, I have fears that just as Maven almost killed
> the developer community for 2.2, announcing a 3.0 now will kill the user
> community.
Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's
trunk? I can understand that people were fed up with Maven at the beginning of the transition
because it was almost impossible to build Cocoon. But that was more than one year ago.
When it comes to user community, I would say that it grows quite nicely. There are people
contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2.
Could it be a good idea that old-timers just take an example of our user's community and overcome
their own prejudices, finally?
[1] http://article.gmane.org/gmane.text.xml.cocoon.user/65605
[2] http://thread.gmane.org/gmane.text.xml.cocoon.user/65389/focus=65416
--
Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Pötz wrote:
> Versioning
> -------------------------------
> For Cocoon 2 there have been proposals that all odd versions are
> development/alpha versions and all even versions are stable releases.
>
> I like this idea and propose that we follow this versioning schema in
> Cocoon 3: All 3.0.x releases are marked as development versions and we
> clearly explain this on the website and the READMEs of all artifacts.
>
> When we believe that the community and the technology are stable, we do
> a 3.1.0 release.
>
> I think this is less confusing than appending alpha, beta or milestone
> postfixes.
>
I would say the contrary. Let's not forget that most of our users aren't
hard-core developers (they love Cocoon because they can do complex stuff
without programming) and they aren't used to this odd/even versioning
scheme that comes from the Linux kernel.
Rather than that, it seems to me that most of the "normal" (i.e. non
hard-core hacker) people consider a version without any "beta",
"milestone" or other suffix as an official stable release. A well-known
example is Firefox that goes through a series of milestones, beta and RC
version before releasing a stable version with the same number. Eclipse
does the same.
Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on
vacation, but I really think this is too early. Cocoon 2.2 is just out
and we announce a 3.0. This will most probably lead people to consider
2.2 as a transition to 3.0 and just not use it, and thus just look
elsewhere. Stated clearly, I have fears that just as Maven almost killed
the developer community for 2.2, announcing a 3.0 now will kill the user
community.
My 0.02 euros.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
<snip/>
>> SVN
>> -------------------------------
>> I'm not sure about the new location in SVN. One option I can think of is
>> http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk, the other is
>> http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3
>>
>> I slightly prefer http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk.
>
> Hmmm. What about http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk
> (and possibly tags, branches as well in future)?
>
> For me repository layout is rather important since I'm using Git to
> access our Subversion repository and I don't want to make it confused by
> all these non-standard layouts.
I have no strong opinion on this. If this works better with git, I'm
fine with your proposal.
<snip/>
>> CI
>> -------------------------------
>> Apache Infrastructure offers a managed Hudson instance. I propose to
>> setup a Cocoon 3 project there.
>
> Why Hudson instead of Continuum?
>
> Is Hudson more flexible or has a better performance? Or just personal
> preference?
Unlike Continuum, I've never had any problems with Hudson. IMO it's also
more intuitive and makes it easy to configure any Maven/JDK combination.
And, it is also smart because it automatically detects upstream and
downstream projects by analyzing the POM structure.
Also Jason seems to be a Hudson fan
(http://maven.markmail.org/message/q6thc63lzby23d5h)
--
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
________________________________________________________________________
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
> Versioning
> -------------------------------
> For Cocoon 2 there have been proposals that all odd versions are
> development/alpha versions and all even versions are stable releases.
>
> I like this idea and propose that we follow this versioning schema in
> Cocoon 3: All 3.0.x releases are marked as development versions and we
> clearly explain this on the website and the READMEs of all artifacts.
>
> When we believe that the community and the technology are stable, we do
> a 3.1.0 release.
>
> I think this is less confusing than appending alpha, beta or milestone
> postfixes.
I have mixed feelings about that but won't block anything.
> SVN
> -------------------------------
> I'm not sure about the new location in SVN. One option I can think of is
> http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk, the other is
> http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3
>
> I slightly prefer http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk.
Hmmm. What about http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk (and possibly tags, branches
as well in future)?
For me repository layout is rather important since I'm using Git to access our Subversion repository
and I don't want to make it confused by all these non-standard layouts.
> Maven
> -------------------------------
> We've already discussed this and the outcome was that we prefer
> functional names:
>
> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
> org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
> org.apache.cocoon.servlet:cocoon-servlet:3.0.0
> org.apache.cocoon.controller:cocoon-controller:3.0.0
> org.apache.cocoon.rest:cocoon-rest:3.0.0
> org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
>
> By using the functional name as part of the groupId, Cocoon 2.2 and
> Cocoon 3 can be used together without getting any problems with the
> dependency resolution mechanisms of Maven or Ivy.
+1
> JAVA NAMESPACES
> -------------------------------
> Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
> are reserved for functional names:
>
> org.apache.cocoon.pipeline
> org.apache.cocoon.sitemap
> org.apache.cocoon.servlet
> org.apache.cocoon.controller
> org.apache.cocoon.rest
> org.apache.cocoon.stringtemplate
+1
> XML NAMESPACES
> -------------------------------
> Corona currently uses three different namespaces in XML documents:
>
> http://apache.org/cocoon/corona/sitemap
> http://apache.org/cocoon/corona/servlet
> http://apache.org/cocoon/corona/controller
>
> These namespaces are without a version number.
>
> Since I don't see how version numbers could help us, I propose
>
> http://apache.org/cocoon/sitemap
> http://apache.org/cocoon/servlet
> http://apache.org/cocoon/controller
Again, mixed feelings but have no strong opinion here as well.
> JIRA
> -------------------------------
> I propose the creation of a COCOON3 project so that Cocoon 2.x and
> Cocoon 3 issues don't get mixed up.
+1
> CI
> -------------------------------
> Apache Infrastructure offers a managed Hudson instance. I propose to
> setup a Cocoon 3 project there.
Why Hudson instead of Continuum?
Is Hudson more flexible or has a better performance? Or just personal preference?
--
Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure [version 2]
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, Aug 20, 2008 at 7:44 AM, Reinhard Pötz <re...@apache.org> wrote:
>
> After our recent discussions, here is my reworked proposal:
<snip>Good looking proposal</snip>
>
> Or do I need a vote before? If so I will start the voting process asap.
> Any opinions?
>
I think you should run a vote, if only for completeness. I don't see
anything controversial (other than the already discussed 3.0 issue) so
I'd imagine it should be straight forward enough.
--
Peter Hunsberger
Renaming Corona to Cocoon 3.0 and infrastructure [version 2]
Posted by Reinhard Pötz <re...@apache.org>.
After our recent discussions, here is my reworked proposal:
Versioning
-------------------------------
Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla,
Maven, Apache Commons, etc.). The first release will be 3.0-alpha-1.
This will be a clear marker that is already visible when you add Cocoon
as a dependency to your build or download the artifacts manually.
Additionally all release artifacts will contain a warning message and an
explanation what "alpha" means.
SVN
-------------------------------
In order to make the life easier for people who use git-svn, I propose
to use the standard SVN directory structure:
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags
Maven
-------------------------------
We use functional names for all artifacts:
org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
org.apache.cocoon.servlet:cocoon-servlet:3.0.0
org.apache.cocoon.controller:cocoon-controller:3.0.0
org.apache.cocoon.rest:cocoon-rest:3.0.0
org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
By using the functional name as part of the groupId, Cocoon 2.2 and
Cocoon 3 can be used together without getting any problems with the
dependency resolution mechanisms of Maven or Ivy.
JAVA NAMESPACES
-------------------------------
Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
are reserved for functional names:
org.apache.cocoon.pipeline
org.apache.cocoon.sitemap
org.apache.cocoon.servlet
org.apache.cocoon.controller
org.apache.cocoon.rest
org.apache.cocoon.stringtemplate
XML NAMESPACES
-------------------------------
Corona currently uses three different namespaces in XML documents:
http://apache.org/cocoon/corona/sitemap
http://apache.org/cocoon/corona/servlet
http://apache.org/cocoon/corona/controller
These namespaces are without a version number.
Since I don't see how version numbers could help, I propose
http://apache.org/cocoon/sitemap
http://apache.org/cocoon/servlet
http://apache.org/cocoon/controller
JIRA
-------------------------------
I propose the creation of a COCOON3 project so that Cocoon 2.x and
Cocoon 3 issues don't get mixed up.
CI
-------------------------------
Apache Infrastructure offers a managed Hudson instance. I propose to
setup a Cocoon 3 project there.
- o -
Any further comments? If there aren't any objections, I will start with
the renaming process next week.
Or do I need a vote before? If so I will start the voting process asap.
Any opinions?
--
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
________________________________________________________________________
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Pötz wrote:
>
>> .
>> Versioning
>> -------------------------------
>> For Cocoon 2 there have been proposals that all odd versions are
>> development/alpha versions and all even versions are stable releases.
>>
>> I like this idea and propose that we follow this versioning schema in
>> Cocoon 3: All 3.0.x releases are marked as development versions and we
>> clearly explain this on the website and the READMEs of all artifacts.
>>
>> When we believe that the community and the technology are stable, we do
>> a 3.1.0 release.
>>
>> I think this is less confusing than appending alpha, beta or milestone
>> postfixes.
>>
+1
>> SVN
>> -------------------------------
>> I'm not sure about the new location in SVN. One option I can think of is
>> http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk, the other is
>> http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3
>>
>> I slightly prefer http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk.
>>
Why wouldn't you use
http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3.0.x? Then
create 3.1.x when it is time for that. Presumably you will create a
3.2.x shortly after that so you can do bug fixes only on 3.1.x and new
development on 3.2.x. If not, then I'm not sure what the point of the
numbering scheme is.
I'm OK with the rest of the proposal.
Renaming Corona to Cocoon 3.0 and infrastructure
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Reinhard Pötz wrote:
>> Following the result of our recent discussion about the future of
>> Corona, I propose Corona to become Cocoon 3.
>>
>> This means that any reference on Corona in source files, package
>> names, artifact ids, group ids or anywhere else will be dropped and
>> the standard Cocoon namespace org.apache.cocoon will be used.
>>
>> This majority vote stays open for 72 hours.
>>
>> Please cast your votes.
>> Here is my +1
>
> During the voting period there were 12 +1 votes and one negative one.
> This means that the proposal was accepted.
>
> For further discussion I will be sending a message to this list that
> describes proposed changes (package name changes, groupId/artifactId,
> versioning, Jira, SVN move, etc.).
Versioning
-------------------------------
For Cocoon 2 there have been proposals that all odd versions are
development/alpha versions and all even versions are stable releases.
I like this idea and propose that we follow this versioning schema in
Cocoon 3: All 3.0.x releases are marked as development versions and we
clearly explain this on the website and the READMEs of all artifacts.
When we believe that the community and the technology are stable, we do
a 3.1.0 release.
I think this is less confusing than appending alpha, beta or milestone
postfixes.
SVN
-------------------------------
I'm not sure about the new location in SVN. One option I can think of is
http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk, the other is
http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3
I slightly prefer http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk.
Maven
-------------------------------
We've already discussed this and the outcome was that we prefer
functional names:
org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
org.apache.cocoon.servlet:cocoon-servlet:3.0.0
org.apache.cocoon.controller:cocoon-controller:3.0.0
org.apache.cocoon.rest:cocoon-rest:3.0.0
org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0
By using the functional name as part of the groupId, Cocoon 2.2 and
Cocoon 3 can be used together without getting any problems with the
dependency resolution mechanisms of Maven or Ivy.
JAVA NAMESPACES
-------------------------------
Coocon 3 will use the "org.apache.cocoon" namespace. The sub-packages
are reserved for functional names:
org.apache.cocoon.pipeline
org.apache.cocoon.sitemap
org.apache.cocoon.servlet
org.apache.cocoon.controller
org.apache.cocoon.rest
org.apache.cocoon.stringtemplate
XML NAMESPACES
-------------------------------
Corona currently uses three different namespaces in XML documents:
http://apache.org/cocoon/corona/sitemap
http://apache.org/cocoon/corona/servlet
http://apache.org/cocoon/corona/controller
These namespaces are without a version number.
Since I don't see how version numbers could help us, I propose
http://apache.org/cocoon/sitemap
http://apache.org/cocoon/servlet
http://apache.org/cocoon/controller
JIRA
-------------------------------
I propose the creation of a COCOON3 project so that Cocoon 2.x and
Cocoon 3 issues don't get mixed up.
CI
-------------------------------
Apache Infrastructure offers a managed Hudson instance. I propose to
setup a Cocoon 3 project there.
Any comments?
--
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
________________________________________________________________________
[summary][vote] Cocoon 3.0
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files, package names,
> artifact ids, group ids or anywhere else will be dropped and the
> standard Cocoon namespace org.apache.cocoon will be used.
>
> This majority vote stays open for 72 hours.
>
> Please cast your votes.
> Here is my +1
During the voting period there were 12 +1 votes and one negative one.
This means that the proposal was accepted.
For further discussion I will be sending a message to this list that
describes proposed changes (package name changes, groupId/artifactId,
versioning, Jira, SVN move, etc.).
--
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
________________________________________________________________________
Re: [vote] Cocoon 3.0
Posted by Joerg Heinicke <jo...@gmx.de>.
Reinhard Pötz <reinhard <at> apache.org> writes:
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
+1
Joerg
RE: [vote] Cocoon 3.0
Posted by Jasha Joachimsthal <j....@onehippo.com>.
> -----Original Message-----
> From: Reinhard Pötz [mailto:reinhard@apache.org]
> Sent: woensdag 6 augustus 2008 13:20
> To: dev@cocoon.apache.org
> Subject: [vote] Cocoon 3.0
>
>
> Following the result of our recent discussion about the
> future of Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files,
> package names, artifact ids, group ids or anywhere else will
> be dropped and the standard Cocoon namespace
> org.apache.cocoon will be used.
+1
Jasha Joachimsthal
www.onehippo.com
Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
Re: [vote] Cocoon 3.0
Posted by Andrew Savory <as...@apache.org>.
Hi
2008/8/6 Reinhard Pötz <re...@apache.org>:
> Following the result of our recent discussion about the future of Corona, I
> propose Corona to become Cocoon 3.
+1
(The king is dead, long live the king!)
Andrew.
--
asavory@apache.org / contact@andrewsavory.com
http://www.andrewsavory.com/
Re: [vote] Cocoon 3.0
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Pötz skrev:
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files, package
> names, artifact ids, group ids or anywhere else will be dropped and
> the standard Cocoon namespace org.apache.cocoon will be used.
+1
/Daniel
Re: [vote] Cocoon 3.0
Posted by Reinhard Pötz <re...@apache.org>.
Alfred Nathaniel wrote:
> On Wed, 2008-08-06 at 13:19 +0200, Reinhard Pötz wrote:
>> Following the result of our recent discussion about the future of
>> Corona, I propose Corona to become Cocoon 3.
>>
>> This means that any reference on Corona in source files, package names,
>> artifact ids, group ids or anywhere else will be dropped and the
>> standard Cocoon namespace org.apache.cocoon will be used.
>>
>> This majority vote stays open for 72 hours.
>>
>> Please cast your votes.
>> Here is my +1
>
> -1
>
> I think it is much too early to proclaim a tiny blossom like Corona to
> be the heir to the huge thicket called Cocoon. It gives the wrong
> signal to potential new users and will make them shy away.
>
> They will read it as: "Oh, they are now working on C3.0. So C2.2 will
> be legacy by the time my project is finished. I may be forced to
> migrate to 3.0 with lots of incompatibilities. Better I use some other
> framework for now.
That doesn't make sense. Then this user would have to migrate from the
'other framework' sometime which is most probably more difficult.
> I'll have another look when C3.1 is out."
>
> At least that was my personal reaction when in 1999 I first came across
> Cocoon. I never bothered with C1.7 because C2.0 was already announced
> as being a complete rewrite. Luckily, I passed by a second time in 2002
> when C2.1 was in beta state.
>
> Evolution instead of revolution is the key to success here.
>
> C2.2 almost killed us because it was very bold and then took very long
> to get out due to the feature creep during the long time it took to get
> out. Porting stuff forward and backward between C2.1 and C2.2 did and
> does cost a lot of resources. I would not want to throw in there yet
> another branch.
There is no need to port things between 2.x and Corona - there is only a
very minimal overlap.
> Before considering C3.0 we should have finished the C2.1 to C2.2
> transition period. And that is not achieved by simply declaring the
> C2.1 branch to be closed. For that I would like to hear more success
> stories where people actually migrated non-trivial apps from C2.1 to
> C2.2.
sure, I'd like to hear them too.
> I don't want to stand in the way of progress here. Please carry on with
> Corona and stay within the Cocoon context but just don't call to
> Cocoon-x.y.
After 25 days of discussion this was the best solution we found. People
were very unhappy with the use of any codename. And meanwhile I think we
are all tired of the name finding game.
Cocoon 3 will be announced as alpha software. We will add warning
messages to all release artifacts and on the homepage that the code is
experimental and contracts can change from patch releases. We will also
state clearly that the focus of Cocoon 3 is much smaller (small pipeline
API & RESTful webservices) and that, thanks to the servlet-service
framework, it can be run very easily in parallel with Cocoon 2.2
> Wasn't the original motivation for Corona to have a
> programmable pipeline container which can be used independently of
> Cocoon?
The original motivation was that Cocoon 2.x code is one of the most
difficult pieces of software that I've ever seen. We tried to refactor
it (see 'Micro-Cocoon' in the whiteboard) but found out that this is
everything else than simple. While doing this I wondered wow many people
do really understand how the environment handling exactly works and can
do changes without a long trial and error period?
> Maybe stupid question: Why can't it be a set of experimental blocks in
> trunk which may lateron replace the current sitemap processor?
It's not only the sitemap processor. Corona also has different contracts
at pipeline and pipeline component level.
--
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
________________________________________________________________________
Re: [vote] Cocoon 3.0
Posted by Alfred Nathaniel <an...@apache.org>.
On Wed, 2008-08-06 at 13:19 +0200, Reinhard Pötz wrote:
> Following the result of our recent discussion about the future of
> Corona, I propose Corona to become Cocoon 3.
>
> This means that any reference on Corona in source files, package names,
> artifact ids, group ids or anywhere else will be dropped and the
> standard Cocoon namespace org.apache.cocoon will be used.
>
> This majority vote stays open for 72 hours.
>
> Please cast your votes.
> Here is my +1
-1
I think it is much too early to proclaim a tiny blossom like Corona to
be the heir to the huge thicket called Cocoon. It gives the wrong
signal to potential new users and will make them shy away.
They will read it as: "Oh, they are now working on C3.0. So C2.2 will
be legacy by the time my project is finished. I may be forced to
migrate to 3.0 with lots of incompatibilities. Better I use some other
framework for now. I'll have another look when C3.1 is out."
At least that was my personal reaction when in 1999 I first came across
Cocoon. I never bothered with C1.7 because C2.0 was already announced
as being a complete rewrite. Luckily, I passed by a second time in 2002
when C2.1 was in beta state.
Evolution instead of revolution is the key to success here.
C2.2 almost killed us because it was very bold and then took very long
to get out due to the feature creep during the long time it took to get
out. Porting stuff forward and backward between C2.1 and C2.2 did and
does cost a lot of resources. I would not want to throw in there yet
another branch.
Before considering C3.0 we should have finished the C2.1 to C2.2
transition period. And that is not achieved by simply declaring the
C2.1 branch to be closed. For that I would like to hear more success
stories where people actually migrated non-trivial apps from C2.1 to
C2.2.
I don't want to stand in the way of progress here. Please carry on with
Corona and stay within the Cocoon context but just don't call to
Cocoon-x.y. Wasn't the original motivation for Corona to have a
programmable pipeline container which can be used independently of
Cocoon?
Maybe stupid question: Why can't it be a set of experimental blocks in
trunk which may lateron replace the current sitemap processor?
Cheers, Alfred.