Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
hepabolu wrote:
Reinhard Poetz said the following on 26/10/07 18:34:
Grzegorz Kossakowski wrote:
BTW. When can we expect new release officialy announced?
I've started to work on it together with a "What's new in Cocoon 2.2"
page and hope to finish it this weekend.
Sorry to reply so late, I'm currently out of internet connection at
home. :-(
thanks Helma. I applied all the proposed corrections.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz said the following on 26/10/07 18:34: Grzegorz Kossakowski wrote: BTW. When can we expect new release officialy announced? I've started to work on it together with a "What's new in Cocoon 2.2" page and hope to finish it this weekend. Sorry to reply so late, I'm currently out of internet connection at home. :-( Anyway, re 141.html: - You state that 'Apache Cocoon is a Spring-based framework'. Shouldn't that be 'Since version 2.2 Apache Cocoon is a Spring-based framework' because earlier versions are not. - A block is the unit of modularization (in comparison: Eclipse uses the term plugins, OSGi bundles) in Cocoon. Better: A block is the unit of modularization in Cocoon (in comparison: Eclipse uses the term plugins, OSGi uses bundles). Note: is that the intention: OSGi uses bundles? If not, please correct. - Everything that goes beyond that what Cocoon provides in... Remove the second 'that'. - A block can provide +THE+ following features: (add 'the') - add commas after each list item and a dot after the last item. - A block is packaged as +A+ Java archive (jar) (add 'a') - (Cocoon Configuration) It's current implementation... should be: Its current implementation... - (Cocoon database) Direct usage of releational databases should be: relational - (Cocoon Flow) ...s for building in... you might as well remove the second space between 'for' and 'building' - (Cocoon Mail) Sitemap components to send mails I'd prefer: emails. - (Cocoon Maven plugin) paching the web.xml at deployment time. should be: patching Re 1420.html: I've gone in and added a few minor changes myself. I'm not sure of the following: - General, last list item: what about it? Is it available, is it configurable. Please complete the sentence. Hope this helps. Bye, Helma
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Giacomo Pati wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
BTW. When can we expect new release officialy announced?
I've started to work on it together with a "What's new in Cocoon 2.2"
page and hope to finish it this weekend.
Could somebody help me please with proof-reading the announcment message
and the "New in Cocoon 2.2" page?
See http://cocoon.zones.apache.org/daisy/cdocs-site-main/1421.html and
...
* special services tht provide pipelines as services
++_that_
corrected
But else seems ok to me.
http://cocoon.zones.apache.org/daisy/cdocs-site-22/1420.html.
So far so good. Is it feasible mentioning the ability for a block to supply
xpatches to patch the
web.xml of the destination cocoon webapp?
yes, definitly worth mentioning it. I added it to the page.
Thanks!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Jeroen Reijn wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
BTW. When can we expect new release officialy announced?
I've started to work on it together with a "What's new in Cocoon 2.2"
page and hope to finish it this weekend.
Could somebody help me please with proof-reading the announcment
message and the "New in Cocoon 2.2" page?
See http://cocoon.zones.apache.org/daisy/cdocs-site-main/1421.html and
This text looks good. Since I'm currently involved with some other work
I'm not sure about all the version numbers, but I trust you on that.
I noticed though that in the sentence:
"Find information about the new features at
http://cocoon.apache.org/2.2/1420_1_1.html.";
The url is not working.
Yes, the page needs to be published.
http://cocoon.zones.apache.org/daisy/cdocs-site-22/1420.html.
What I've read so far seems fine. As you know I've not done that much
with 2.2 yet, so I cannot really add more information on this subject.
The page looks well structured and sums up most of the things I've heard
and seen about 2.2.
Thanks for the feedback!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > Reinhard Poetz wrote: >> Grzegorz Kossakowski wrote: >>> BTW. When can we expect new release officialy announced? >> >> I've started to work on it together with a "What's new in Cocoon 2.2" >> page and hope to finish it this weekend. > > Could somebody help me please with proof-reading the announcment message > and the "New in Cocoon 2.2" page? > > See http://cocoon.zones.apache.org/daisy/cdocs-site-main/1421.html and ... * special services tht provide pipelines as services ++_that_ But else seems ok to me. > http://cocoon.zones.apache.org/daisy/cdocs-site-22/1420.html. So far so good. Is it feasible mentioning the ability for a block to supply xpatches to patch the web.xml of the destination cocoon webapp? Ciao and thanks - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHJZ3HLNdJvZjjVZARAmoGAJ0QP0GNjagBN7YYzwONguNT3760YACg2RHK hDF1Srt3KYXrp3Tv6He5wV8= =/afQ -END PGP SIGNATURE-
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz wrote: Reinhard Poetz wrote: Grzegorz Kossakowski wrote: BTW. When can we expect new release officialy announced? I've started to work on it together with a "What's new in Cocoon 2.2" page and hope to finish it this weekend. Could somebody help me please with proof-reading the announcment message and the "New in Cocoon 2.2" page? See http://cocoon.zones.apache.org/daisy/cdocs-site-main/1421.html and This text looks good. Since I'm currently involved with some other work I'm not sure about all the version numbers, but I trust you on that. I noticed though that in the sentence: "Find information about the new features at http://cocoon.apache.org/2.2/1420_1_1.html."; The url is not working. http://cocoon.zones.apache.org/daisy/cdocs-site-22/1420.html. What I've read so far seems fine. As you know I've not done that much with 2.2 yet, so I cannot really add more information on this subject. The page looks well structured and sums up most of the things I've heard and seen about 2.2. Jeroen TIA
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
BTW. When can we expect new release officialy announced?
I've started to work on it together with a "What's new in Cocoon 2.2"
page and hope to finish it this weekend.
Could somebody help me please with proof-reading the announcment message and the
"New in Cocoon 2.2" page?
See http://cocoon.zones.apache.org/daisy/cdocs-site-main/1421.html and
http://cocoon.zones.apache.org/daisy/cdocs-site-22/1420.html.
TIA
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Grzegorz Kossakowski wrote:
BTW. When can we expect new release officialy announced?
I've started to work on it together with a "What's new in Cocoon 2.2" page and
hope to finish it this weekend.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz pisze: > > The relese of these artifacts has been accepted by 5 +1 votes and no -1. > I will move the artifacts into the Apache Maven M2 sync repository asap > and also prepare an announcement mail. I was late on voting (gosh, I'm really busy now...) but I would like to say that I tested RC2 and everything seems to work ok. I'm also very happy to see it's happening and I think some kudos should really go to Reinhard for taking care of preparing release. BTW. When can we expect new release officialy announced? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[result][vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz wrote:
I've prepared another series of releases from trunk, see the list of all 45
artifacts below.
[...]
SUBPROJECT: COCOON CONFIGURATION
- cocoon-configuration-api-1.0.1.jar
- cocoon-spring-configurator-1.0.1.jar
SUBPROJECT: COCOON SERVLET-SERVICE-FRAMEWORK
- cocoon-servlet-service-impl-1.0.0-RC1.jar
- cocoon-servlet-service-components-1.0.0-RC1.jar
COCOON CORE
- cocoon-xml-api-1.0.0-RC2.jar
- cocoon-xml-impl-1.0.0-RC2.jar
- cocoon-xml-resolver-1.0.0-RC2.jar
- cocoon-xml-util-1.0.0-RC2.jar
- cocoon-thread-api-1.0.0-RC2.jar
- cocoon-thread-impl-1.0.0-RC2.jar
- cocoon-expression-language-api-1.0.0-RC2.jar
- cocoon-expression-language-impl-1.0.0-RC2.jar
- cocoon-util-1.0.0-RC2.jar
- cocoon-store-impl-1.0.0-RC2.jar
- cocoon-pipeline-api-1.0.0-RC2.jar
- cocoon-pipeline-impl-1.0.0-RC2.jar
- cocoon-pipeline-impl-1.0.0-RC2-tests.jar
- cocoon-pipeline-components-1.0.0-RC2.jar
- cocoon-sitemap-api-1.0.0-RC2.jar
- cocoon-sitemap-impl-1.0.0-RC2.jar
- cocoon-sitemap-impl-1.0.0-RC2-tests.jar
- cocoon-sitemap-components-1.0.0-RC2.jar
- cocoon-core-2.2.0-RC2.jar
- cocoon-core-2.2.0-RC2-tests.jar
COCOON BLOCKS
- cocoon-template-impl-1.0.0-RC2.jar
- cocoon-flowscript-impl-1.0.0-RC2.jar
- cocoon-auth-api-1.0.0-RC2.jar
- cocoon-auth-impl-1.0.0-RC2.jar
- cocoon-batik-impl-1.0.0-RC2.jar
- cocoon-captcha-impl-1.0.0-RC2.jar
- cocoon-fop-impl-1.0.0-RC2.jar
- cocoon-html-impl-1.0.0-RC2.jar
- cocoon-linkrewriter-impl-1.0.0-RC2.jar
- cocoon-mail-impl-1.0.0-RC2.jar
- cocoon-databases-hsqldb-client-1.0.0-RC2.jar
- cocoon-databases-hsqldb-server-1.0.0-RC2.jar
- cocoon-databases-mocks-1.0.0-RC2.jar
- cocoon-databases-impl-1.0.0-RC2.jar
- cocoon-ajax-impl-1.0.0-RC1.jar
- cocoon-apples-impl-1.0.0-RC2.jar
- cocoon-forms-impl-1.0.0-RC1.jar
COCOON ARCHETYPES
- cocoon-22-archetype-block-1.0.0-RC2.jar
- cocoon-22-archetype-block-plain-1.0.0-RC2.jar
- cocoon-22-archetype-webapp-1.0.0-RC2.jar
COCOON TOOLS
- cocoon-maven-javadocs-script-report-1.0.0-M1.jar[1]
The relese of these artifacts has been accepted by 5 +1 votes and no -1. I will
move the artifacts into the Apache Maven M2 sync repository asap and also
prepare an announcement mail.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
On 15.10.2007 3:38 Uhr, Reinhard Poetz wrote: I've prepared another series of releases from trunk, see the list of all 45 artifacts below. This time most of the modules are proposed to be released as "RC2" (release candidate 2) or "RC1". +1 Joerg
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz wrote: I've prepared another series of releases from trunk, see the list of all 45 artifacts below. ... - cocoon-configuration-api-1.0.1.jar - cocoon-spring-configurator-1.0.1.jar - cocoon-servlet-service-impl-1.0.0-RC1.jar - cocoon-servlet-service-components-1.0.0-RC1.jar - cocoon-xml-api-1.0.0-RC2.jar - cocoon-xml-impl-1.0.0-RC2.jar - cocoon-xml-resolver-1.0.0-RC2.jar - cocoon-xml-util-1.0.0-RC2.jar - cocoon-thread-api-1.0.0-RC2.jar - cocoon-thread-impl-1.0.0-RC2.jar - cocoon-expression-language-api-1.0.0-RC2.jar - cocoon-expression-language-impl-1.0.0-RC2.jar - cocoon-util-1.0.0-RC2.jar - cocoon-store-impl-1.0.0-RC2.jar - cocoon-pipeline-api-1.0.0-RC2.jar - cocoon-pipeline-impl-1.0.0-RC2.jar - cocoon-pipeline-impl-1.0.0-RC2-tests.jar - cocoon-pipeline-components-1.0.0-RC2.jar - cocoon-sitemap-api-1.0.0-RC2.jar - cocoon-sitemap-impl-1.0.0-RC2.jar - cocoon-sitemap-impl-1.0.0-RC2-tests.jar - cocoon-sitemap-components-1.0.0-RC2.jar - cocoon-core-2.2.0-RC2.jar - cocoon-core-2.2.0-RC2-tests.jar - cocoon-template-impl-1.0.0-RC2.jar - cocoon-flowscript-impl-1.0.0-RC2.jar - cocoon-auth-api-1.0.0-RC2.jar - cocoon-auth-impl-1.0.0-RC2.jar - cocoon-batik-impl-1.0.0-RC2.jar - cocoon-captcha-impl-1.0.0-RC2.jar - cocoon-fop-impl-1.0.0-RC2.jar - cocoon-html-impl-1.0.0-RC2.jar - cocoon-linkrewriter-impl-1.0.0-RC2.jar - cocoon-mail-impl-1.0.0-RC2.jar - cocoon-databases-hsqldb-client-1.0.0-RC2.jar - cocoon-databases-hsqldb-server-1.0.0-RC2.jar - cocoon-databases-mocks-1.0.0-RC2.jar - cocoon-databases-impl-1.0.0-RC2.jar - cocoon-ajax-impl-1.0.0-RC1.jar - cocoon-apples-impl-1.0.0-RC2.jar - cocoon-forms-impl-1.0.0-RC1.jar - cocoon-22-archetype-block-1.0.0-RC2.jar - cocoon-22-archetype-block-plain-1.0.0-RC2.jar - cocoon-22-archetype-webapp-1.0.0-RC2.jar - cocoon-maven-javadocs-script-report-1.0.0-M1.jar[1] +1 Vadim
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz schrieb: > > I've prepared another series of releases from trunk. +1
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
On 10/15/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > I've prepared another series of releases from trunk, see the list of all 45 > artifacts below. This time most of the modules are proposed to be released as > "RC2" (release candidate 2) or "RC1". > Nicely done. +1 -- Peter Hunsberger
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Leszek Gawron wrote: Reinhard Poetz wrote: Reinhard Poetz wrote: I've prepared another series of releases from trunk +1 We need to revert CTemplate springification for RC2, what about CForms? Sorry about the noise - I forgot those are branched. The CTemplate release is ok. -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz wrote: Reinhard Poetz wrote: I've prepared another series of releases from trunk +1 We need to revert CTemplate springification for RC2, what about CForms? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 & others
Reinhard Poetz wrote:
I've prepared another series of releases from trunk
+1
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
[vote] Releasing from trunk: Cocoon 2.2-RC2 & others
I've prepared another series of releases from trunk, see the list of all 45
artifacts below. This time most of the modules are proposed to be released as
"RC2" (release candidate 2) or "RC1".
This is probably be the last release before the final release of all those
modules. For this final release we will mostly work on backwards-compatibilty,
cleaning up tasks and consistent deprecation.
You can find the staged files for all modules (sources, binaries, javadocs +
checksums + gpg signatures) at
- http://people.apache.org/builds/cocoon/
(Maven 2 repo)
- http://people.apache.org/builds/cocoon/cocoon-2.2RC2-all.tar.gz
(tar archive of all artifacts).
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/.
Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!
This majority vote stays open for 72 hours.
SUBPROJECT: COCOON CONFIGURATION
- cocoon-configuration-api-1.0.1.jar
- cocoon-spring-configurator-1.0.1.jar
SUBPROJECT: COCOON SERVLET-SERVICE-FRAMEWORK
- cocoon-servlet-service-impl-1.0.0-RC1.jar
- cocoon-servlet-service-components-1.0.0-RC1.jar
COCOON CORE
- cocoon-xml-api-1.0.0-RC2.jar
- cocoon-xml-impl-1.0.0-RC2.jar
- cocoon-xml-resolver-1.0.0-RC2.jar
- cocoon-xml-util-1.0.0-RC2.jar
- cocoon-thread-api-1.0.0-RC2.jar
- cocoon-thread-impl-1.0.0-RC2.jar
- cocoon-expression-language-api-1.0.0-RC2.jar
- cocoon-expression-language-impl-1.0.0-RC2.jar
- cocoon-util-1.0.0-RC2.jar
- cocoon-store-impl-1.0.0-RC2.jar
- cocoon-pipeline-api-1.0.0-RC2.jar
- cocoon-pipeline-impl-1.0.0-RC2.jar
- cocoon-pipeline-impl-1.0.0-RC2-tests.jar
- cocoon-pipeline-components-1.0.0-RC2.jar
- cocoon-sitemap-api-1.0.0-RC2.jar
- cocoon-sitemap-impl-1.0.0-RC2.jar
- cocoon-sitemap-impl-1.0.0-RC2-tests.jar
- cocoon-sitemap-components-1.0.0-RC2.jar
- cocoon-core-2.2.0-RC2.jar
- cocoon-core-2.2.0-RC2-tests.jar
COCOON BLOCKS
- cocoon-template-impl-1.0.0-RC2.jar
- cocoon-flowscript-impl-1.0.0-RC2.jar
- cocoon-auth-api-1.0.0-RC2.jar
- cocoon-auth-impl-1.0.0-RC2.jar
- cocoon-batik-impl-1.0.0-RC2.jar
- cocoon-captcha-impl-1.0.0-RC2.jar
- cocoon-fop-impl-1.0.0-RC2.jar
- cocoon-html-impl-1.0.0-RC2.jar
- cocoon-linkrewriter-impl-1.0.0-RC2.jar
- cocoon-mail-impl-1.0.0-RC2.jar
- cocoon-databases-hsqldb-client-1.0.0-RC2.jar
- cocoon-databases-hsqldb-server-1.0.0-RC2.jar
- cocoon-databases-mocks-1.0.0-RC2.jar
- cocoon-databases-impl-1.0.0-RC2.jar
- cocoon-ajax-impl-1.0.0-RC1.jar
- cocoon-apples-impl-1.0.0-RC2.jar
- cocoon-forms-impl-1.0.0-RC1.jar
COCOON ARCHETYPES
- cocoon-22-archetype-block-1.0.0-RC2.jar
- cocoon-22-archetype-block-plain-1.0.0-RC2.jar
- cocoon-22-archetype-webapp-1.0.0-RC2.jar
COCOON TOOLS
- cocoon-maven-javadocs-script-report-1.0.0-M1.jar[1]
[1] Only needed for internal reasons: When a release artifact is created all
plugins and dependencies mustn't be SNAPSHOT versions. Since we create the docs
at the same time and the javadocs-script-report is part of the offical
documentation,
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
[result][vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 3)
The proposed modules have been accepted by 4 +1 (Giacomo voted at a different
thread but meant "take 3") and 1 +0 vote. I will move the artifacts into the
Apache Maven M2 sync repository asap.
I will work on the website and an announcement mail but this will take some more
time though.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
Giacomo Pati wrote:
Grzegorz Kossakowski wrote:
Giacomo Pati pisze:
I could confirm that Cocoon was working up to last friday. But after
updating my local repo an hour
ago or so, I'm facing serious problems with Cocoon throwing an
exception like the one below so I
have to revert my previous vote to a _-1_:
Do you use Cocoon from trunk or Cocoon from staging repo that we vote on?
Sorry, I meant trunk so I missread Reinhards mail and thus can give again a +1
for the stuff in the staging repo.
But anyway, something beyond revision 552148 has broke trunk.
yes, see the "svn commit: r552371 - trunk broken, help needed" thread.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > Giacomo Pati pisze: > >> I could confirm that Cocoon was working up to last friday. But after >> updating my local repo an hour >> ago or so, I'm facing serious problems with Cocoon throwing an >> exception like the one below so I >> have to revert my previous vote to a _-1_: > > Do you use Cocoon from trunk or Cocoon from staging repo that we vote on? Sorry, I meant trunk so I missread Reinhards mail and thus can give again a +1 for the stuff in the staging repo. But anyway, something beyond revision 552148 has broke trunk. Ciao and thanks. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGiRwPLNdJvZjjVZARAqb3AKCL8H4t/POoVylqaOXZ6e9NtII9OQCgrCWm ZwhlCr2gIrRvGnNMG08oOdU= =dGQA -END PGP SIGNATURE-
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
Giacomo Pati pisze: I could confirm that Cocoon was working up to last friday. But after updating my local repo an hour ago or so, I'm facing serious problems with Cocoon throwing an exception like the one below so I have to revert my previous vote to a _-1_: Do you use Cocoon from trunk or Cocoon from staging repo that we vote on? Caused by: org.mozilla.javascript.EcmaError: ReferenceError: "cocoon" is not defined. (#1) at org.apache.cocoon.template.instruction.Call.execute(Call.java:149) at org.apache.cocoon.template.script.Invoker.execute(Invoker.java:70) at org.apache.cocoon.template.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:140) at org.apache.cocoon.template.JXTemplateGenerator.generate(JXTemplateGenerator.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72) at $Proxy9.generate(Unknown Source) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:542) ... 122 more Caused by: org.mozilla.javascript.EcmaError: ReferenceError: "cocoon" is not defined. (#1) at org.apache.cocoon.template.instruction.Set.execute(Set.java:79) at org.apache.cocoon.template.script.Invoker.execute(Invoker.java:73) at org.apache.cocoon.template.instruction.Call.execute(Call.java:145) ... 132 more Caused by: org.mozilla.javascript.EcmaError: ReferenceError: "cocoon" is not defined. (#1) at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3229) at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3219) at org.mozilla.javascript.ScriptRuntime.notFoundError(ScriptRuntime.java:3292) at org.mozilla.javascript.ScriptRuntime.nameOrFunction(ScriptRuntime.java:1636) at org.mozilla.javascript.ScriptRuntime.name(ScriptRuntime.java:1575) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3162) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251) at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:175) at org.apache.cocoon.components.expression.javascript.JavaScriptExpression.evaluate(JavaScriptExpression.java:76) at org.apache.cocoon.components.expression.javascript.JavaScriptExpression.getNode(JavaScriptExpression.java:116) at org.apache.cocoon.template.expression.JXTExpression.getNode(JXTExpression.java:57) at org.apache.cocoon.template.instruction.Set.execute(Set.java:76) ... 134 more The error is similar to the one described here: http://article.gmane.org/gmane.text.xml.cocoon.devel/73877 So if it's not working for you it's my fault and my working on fixing it. However, you must be aware that release we vote on is already prepared so my changes do _not_ affect it. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giacomo Pati wrote: > > > Reinhard Poetz wrote: >> You can find the staged versions of the modules (sources, binaries, >> javadocs + >> checksums + gpg signatures) at http://people.apache.org/builds/cocoon/. >> SVN tags >> of all these artifacts can be found at >> http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp >> key into the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS. >> Find instructions about how you can test in a seperate mail. Report your >> findings to that thread and use this one for voting only. Thanks! > > Sorry for being late. > > As we're working since a long time with C22 for projects here I can give a > > +1 I could confirm that Cocoon was working up to last friday. But after updating my local repo an hour ago or so, I'm facing serious problems with Cocoon throwing an exception like the one below so I have to revert my previous vote to a _-1_: 2007-07-02 15:46:55 [ERROR] btpool0-3 cocoon - Failed to process pipeline at [EcmaError] - [unknown location] at [SAXParseException] - servlet:forms:/resource/internal/generation/jx-macros.xml:47:101 at [SAXParseException] - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/forms/expenditures/template.xml:13:45 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:131:42 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:116:43 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:115:53 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:114:80 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:108:52 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:105:36 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:104:36 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:103:58 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:99:79 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:98:35 at [script] - [unknown location] at servlet:forms:/resource/internal/flow/javascript/Form.js:257 at expenditures - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/forms/expenditures/flow.js:37 at main - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/flow/reporting.js:33 at handleForm - servlet:forms:/resource/internal/flow/javascript/Form.js:414 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:234:41 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:233:165 org.apache.cocoon.ProcessingException: Failed to process pipeline at [EcmaError] - [unknown location] at [SAXParseException] - servlet:forms:/resource/internal/generation/jx-macros.xml:47:101 at [SAXParseException] - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/forms/expenditures/template.xml:13:45 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:131:42 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:116:43 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:115:53 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:114:80 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:108:52 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:105:36 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:104:36 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:103:58 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:99:79 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:98:35 at [script] - [unknown location] at servlet:forms:/resource/internal/flow/javascript/Form.js:257 at expenditures - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/forms/expenditures/flow.js:37 at main - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/flow/reporting.js:33 at handleForm - servlet:forms:/resource/internal/flow/javascript/Form.js:414 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:234:41 at - file:/home/giacomo/svn/otego/reporting/./src/main/resources/COB-INF/sitemap.xmap:233:165 at org.apache.c
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 3)
Reinhard Poetz schrieb: > > I prepared another series of releases from trunk, see the list of all 43 > modules below. Most of them are proposed to be released as "RC1" > (release candidate 1). The exceptions are > > - the forms and the ajax block which need more work related to their > usage >of the servlet service framework > - the servlet-service framework which introduces some contracts >that are under discussion > - the Cocoon Maven 2 plugin which needs more user feedback > Sorry for being late. We are working since a long time with C22 and it works fine. I haven't tested all the modules but +1 from my side also. With the RCL-plugin I still have my problems but I can't say if it's a problem of my configurations or of the RCL-plugin (not the same problems like Giacomo). Thus I don't consider my problems as a showstopper. Regards Felix
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > > You can find the staged versions of the modules (sources, binaries, > javadocs + > checksums + gpg signatures) at http://people.apache.org/builds/cocoon/. > SVN tags > of all these artifacts can be found at > http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp > key into the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS. > Find instructions about how you can test in a seperate mail. Report your > findings to that thread and use this one for voting only. Thanks! Sorry for being late. As we're working since a long time with C22 for projects here I can give a +1 for it even if I haven't tested all the modules proposed. There are some itches left (RCL-Plugin) IMHO but they are for sure no show stoppers. Ciao and thanks - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGiJ2uLNdJvZjjVZARAm6WAJ9oV8UyrZZI9MACvaiKpVm/TidgOQCgizFl y0pnPDOzbC13HIVim68f87o= =643A -END PGP SIGNATURE-
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 3)
Reinhard Poetz wrote: Because of Vadim's findings (http://marc.info/?l=xml-cocoon-dev&m=118295221205686&w=2) I've recreated following release artifacts org.apache.cocoon.cocoon:4 org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1 org.apache.cocoon:cocoon-core:2.2.0-RC1 Thanks for all your effort Reinhard. Here is my +0 again :-)
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 3)
Reinhard Poetz pisze: Because of Vadim's findings (http://marc.info/?l=xml-cocoon-dev&m=118295221205686&w=2) I've recreated following release artifacts org.apache.cocoon.cocoon:4 org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1 org.apache.cocoon:cocoon-core:2.2.0-RC1 Reinhard, I've searched all jars for NOTICE and LICENSE files and no jar is lacking any of them. Here is my: +1 Thanks for your effort, again! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 3)
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 3)
Because of Vadim's findings
(http://marc.info/?l=xml-cocoon-dev&m=118295221205686&w=2) I've recreated
following release artifacts
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1
- o -
I prepared another series of releases from trunk, see the list of all 43
modules below. Most of them are proposed to be released as "RC1" (release
candidate 1). The exceptions are
- the forms and the ajax block which need more work related to their usage
of the servlet service framework
- the servlet-service framework which introduces some contracts
that are under discussion
- the Cocoon Maven 2 plugin which needs more user feedback
The release of "release candidates" means that we don't/can't change contracts
without a deprecation period (e.g. deprecate something in 2.2.x, keep it in
2.3.x and remove it in 2.4.x or 3.x).
You can find the staged artifacts of all modules (sources, binaries, javadocs +
checksums + pgp signatures) at
- http://people.apache.org/builds/cocoon/
(Maven 2 repo)
- http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz
(tar archive of all artifacts).
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into
the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.
Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!
This majority vote stays open for 72 hours.
Finally, here's the list of modules to be voted on:
Core artifacts (jar)
org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
org.apache.cocoon:cocoon-util:1.0.0-RC1
org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1
Subproject: Servlet-Service (jar)
-
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2
Blocks (jar)
org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1
org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3
Maven plugins, archetypes and related (jar)
---
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1
org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1
POM artifacts
-
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-core-modules:4
org.apache.cocoon:cocoon-blocks-modules:4
org.apache.cocoon:cocoon-tools-modules:4
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
All of maven-metadata.xml files have no license header either. Do we really have to add our license header to those files? AFAICS nobody does it. Do they really contain (enough) protectable intellectual property? I don't think so. Me neither. I think that's nitpicking. It's more than questionable and it would have to be fixed by the maven guys. cheers -- Torsten
[result][vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Since no PMC can overrule ASF wide release guidelines (see Vadim's findings), we
can't release the proposed artifacts as they are.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Vadim Gritsenko wrote:
cocoon-core-2.2.0-RC1-tests.jar and
cocoon-pipeline-impl-1.0.0-RC1-tests.jar have no required LICENSE,
NOTICE files.
*argh*
cocoon-4.pom file has no license header.
I guess it got lost after the first release :-(
All of maven-metadata.xml files have no license header either.
Do we really have to add our license header to those files? AFAICS nobody does
it. Do they really contain (enough) protectable intellectual property? I don't
think so.
- o -
Anyway, I have to release cocoon-4, cocoon-core-2.2.0-RC1-tests and
cocoon-pipeline-impl-1.0.0-RC1-tests again. Since all other modules depend on
them, this stops the release of all other artifacts too :-(
The problem is that
a) I'm not sure how to add LICENSE and NOTICE to the _old_ code.
I guess I have to create branches of those modules first,
add the files there and run mvn release again.
b) I don't have much time for opensource stuff ATM hence I can't say
when I can do it. Sorry.
If somebody has more time for the release of the three artifacts, just let me
know ...
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Torsten Curdt wrote: All of maven-metadata.xml files have no license header either. Dejavu? We had that on commons already ;) IMO not required to have a license in there. Shrug. :) As I've said I've no idea if this is indeed not required. Vadim
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
All of maven-metadata.xml files have no license header either. Dejavu? We had that on commons already ;) IMO not required to have a license in there. cheers -- Torsten
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Reinhard Poetz wrote: I prepared another series of releases from trunk, see the list of all 43 artifacts below. ... Core artifacts (jar) org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1 org.apache.cocoon:cocoon-util:1.0.0-RC1 org.apache.cocoon:cocoon-xml-api:1.0.0-RC1 org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1 org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1 org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1 org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1 org.apache.cocoon:cocoon-thread-api:1.0.0-RC1 org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1 org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1 org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1 org.apache.cocoon:cocoon-store-impl:1.0.0-RC1 org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1 org.apache.cocoon:cocoon-core:2.2.0-RC1 cocoon-core-2.2.0-RC1-tests.jar and cocoon-pipeline-impl-1.0.0-RC1-tests.jar have no required LICENSE, NOTICE files. Subproject: Servlet-Service (jar) - org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2 org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2 Blocks (jar) org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1 org.apache.cocoon:cocoon-template-impl:1.0.0-RC1 org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1 org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1 org.apache.cocoon:cocoon-auth-api:1.0.0-RC1 org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1 org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1 org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1 org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1 org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1 org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1 org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1 org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1 org.apache.cocoon:cocoon-html-impl:1.0.0-RC1 org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1 org.apache.cocoon:cocoon-forms-impl:1.0.0-M3 org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3 Maven plugins, archetypes and related (jar) --- org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1 org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1 org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1 POM artifacts - org.apache.cocoon.cocoon:4 cocoon-4.pom file has no license header. All of maven-metadata.xml files have no license header either. Vadim
Re: [REMINDER] Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Hi all, I'm afraid it's the same here. I've been going through some samples. They seem to be fine, but I've been too occupied lately to give a good vote. So +0 on my behalve. Regards, Jeroen Reijn Joerg Heinicke wrote: On 26.06.2007 19:32, Ralph Goers wrote: The best I could do would be +0. I haven't had time to work with it. Unfortunately the same here. Joerg
Re: [REMINDER] Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
On 26.06.2007 19:32, Ralph Goers wrote: The best I could do would be +0. I haven't had time to work with it. Unfortunately the same here. Joerg
Re: [REMINDER] Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
The best I could do would be +0. I haven't had time to work with it. Ralph Grzegorz Kossakowski wrote: Reinhard Poetz pisze: I prepared another series of releases from trunk, see the list of all 43 artifacts below. The problems with references to snapshots and the usage of the repository element in some of the poms are sorted out. This majority vote stays open for 120 hours. Call me a greenhorn but I'm really concerned that we have only two votes, yet. I hope to see crowd that decided to surprise me and is going to vote just before deadline... :-)
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
+1
[REMINDER] Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Reinhard Poetz pisze: I prepared another series of releases from trunk, see the list of all 43 artifacts below. The problems with references to snapshots and the usage of the repository element in some of the poms are sorted out. This majority vote stays open for 120 hours. Call me a greenhorn but I'm really concerned that we have only two votes, yet. I hope to see crowd that decided to surprise me and is going to vote just before deadline... :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Reinhard Poetz wrote:
You can find the staged versions of all modules (sources, binaries,
javadocs +
checksums + gpg signatures) at
- http://people.apache.org/builds/cocoon/
(Maven 2 repo)
- http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz
(tar archive of all artifacts).
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp
key into the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.
Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!
This majority vote stays open for 120 hours.
Finally, here's the list of modules to be voted on:
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
Reinhard Poetz pisze: I prepared another series of releases from trunk, see the list of all 43 artifacts below. The problems with references to snapshots and the usage of the repository element in some of the poms are sorted out. Most of the modules are proposed to be released as "RC1" (release candidate 1). The exceptions are - the forms and the ajax block which need more work related to their usage of the servlet service framework - the servlet-service framework which introduces some contracts that are under discussion - the Cocoon Maven 2 plugin which needs more user feedback The release of "release candidates" means that we don't/can't change contracts without a deprecation period (e.g. deprecate something in 2.2.x, keep it in 2.3.x and remove it in 2.4.x or 3.x). You can find the staged versions of all modules (sources, binaries, javadocs + checksums + gpg signatures) at - http://people.apache.org/builds/cocoon/ (Maven 2 repo) - http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz (tar archive of all artifacts). SVN tags of all these artifacts can be found at http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS. Find instructions about how you can test in a seperate mail. Report your findings to that thread and use this one for voting only. Thanks! This majority vote stays open for 120 hours. Finally, here's the list of modules to be voted on: Core artifacts (jar) org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1 org.apache.cocoon:cocoon-util:1.0.0-RC1 org.apache.cocoon:cocoon-xml-api:1.0.0-RC1 org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1 org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1 org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1 org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1 org.apache.cocoon:cocoon-thread-api:1.0.0-RC1 org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1 org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1 org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1 org.apache.cocoon:cocoon-store-impl:1.0.0-RC1 org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1 org.apache.cocoon:cocoon-core:2.2.0-RC1 Subproject: Servlet-Service (jar) - org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2 org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2 Blocks (jar) org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1 org.apache.cocoon:cocoon-template-impl:1.0.0-RC1 org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1 org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1 org.apache.cocoon:cocoon-auth-api:1.0.0-RC1 org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1 org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1 org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1 org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1 org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1 org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1 org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1 org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1 org.apache.cocoon:cocoon-html-impl:1.0.0-RC1 org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1 org.apache.cocoon:cocoon-forms-impl:1.0.0-M3 org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3 Maven plugins, archetypes and related (jar) --- org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1 org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1 org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1 POM artifacts - org.apache.cocoon.cocoon:4 org.apache.cocoon:cocoon-core-modules:4 org.apache.cocoon:cocoon-blocks-modules:4 org.apache.cocoon:cocoon-tools-modules:4 I tested it briefly, keys are fine, here is my: +1 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[vote] Releasing from trunk: Cocoon 2.2-RC1 & others (take 2)
I prepared another series of releases from trunk, see the list of all 43
artifacts below. The problems with references to snapshots and the usage of the
repository element in some of the poms are sorted out.
Most of the modules are proposed to be released as "RC1" (release candidate 1).
The exceptions are
- the forms and the ajax block which need more work related to their usage
of the servlet service framework
- the servlet-service framework which introduces some contracts
that are under discussion
- the Cocoon Maven 2 plugin which needs more user feedback
The release of "release candidates" means that we don't/can't change contracts
without a deprecation period (e.g. deprecate something in 2.2.x, keep it in
2.3.x and remove it in 2.4.x or 3.x).
You can find the staged versions of all modules (sources, binaries, javadocs +
checksums + gpg signatures) at
- http://people.apache.org/builds/cocoon/
(Maven 2 repo)
- http://people.apache.org/builds/cocoon/cocoon-2.2RC1-all.tar.gz
(tar archive of all artifacts).
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into
the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.
Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!
This majority vote stays open for 120 hours.
Finally, here's the list of modules to be voted on:
Core artifacts (jar)
org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
org.apache.cocoon:cocoon-util:1.0.0-RC1
org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1
Subproject: Servlet-Service (jar)
-
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2
Blocks (jar)
org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1
org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3
Maven plugins, archetypes and related (jar)
---
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1
org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1
POM artifacts
-
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-core-modules:4
org.apache.cocoon:cocoon-blocks-modules:4
org.apache.cocoon:cocoon-tools-modules:4
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
Because of Joakim's and Grek's findings, I hereby withdraw the vote. I will
provide the corrected artifacts
org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1
org.apache.cocoon.cocoon:4
as soon as commons-jci is available on the central Maven repo and start the vote
then again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I prepared another series of releases from trunk, see the list of all 43
artifacts below.
...
You can find the staged versions of the modules (sources, binaries,
javadocs + checksums + gpg signatures) at
http://people.apache.org/builds/cocoon/.
To produce a binding vote, I'd have to download each artifact and peek
inside it. Given sheer number of files in the download location, it is
practically impossible (short of mirroring the whole directory or
creating .tar.bz2 by myself and downloading it). To simplify release
checking process for all PMC members - can you create a single (or
couple of - but not dozens!) download file? Thanks.
here you are:
http://people.apache.org/builds/cocoon/cocoon-2.2RC1_staging.tar.gz
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
Reinhard Poetz wrote: I prepared another series of releases from trunk, see the list of all 43 artifacts below. ... You can find the staged versions of the modules (sources, binaries, javadocs + checksums + gpg signatures) at http://people.apache.org/builds/cocoon/. To produce a binding vote, I'd have to download each artifact and peek inside it. Given sheer number of files in the download location, it is practically impossible (short of mirroring the whole directory or creating .tar.bz2 by myself and downloading it). To simplify release checking process for all PMC members - can you create a single (or couple of - but not dozens!) download file? Thanks. Without checking files, I'd have to vote -0. Vadim
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others
Reinhard Poetz wrote:
You can find the staged versions of the modules (sources, binaries,
javadocs +
checksums + gpg signatures) at http://people.apache.org/builds/cocoon/.
SVN tags
of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/.
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[vote] Releasing from trunk: Cocoon 2.2-RC1 & others
I prepared another series of releases from trunk, see the list of all 43
artifacts below. This time most of the modules are proposed to be released as
"RC1" (release candidate 1). The exceptions are
- the forms and the ajax block which need more work related to their usage
of the servlet service framework
- the servlet-service framework which introduces some contracts
that are under discussion
- the Cocoon Maven 2 plugin which has a dependency on Commons JCI which
hasn't been releases as "final" yet.
The release of "release candidates" means that we don't/can't change contracts
without a deprecation period (e.g. deprecate something in 2.2.x, keep it in
2.3.x and remove it in 2.4.x or 3.x).
You can find the staged versions of the modules (sources, binaries, javadocs +
checksums + gpg signatures) at http://people.apache.org/builds/cocoon/. SVN tags
of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. I put my pgp key into
the http://svn.apache.org/repos/asf/cocoon/trunk/commons/KEYS.
Find instructions about how you can test in a seperate mail. Report your
findings to that thread and use this one for voting only. Thanks!
This majority vote stays open for 72 hours.
Finally, here's the list of modules to be voted on:
Core artifacts (jar)
org.apache.cocoon:cocoon-pipeline-api:1.0.0-RC1
org.apache.cocoon:cocoon-util:1.0.0-RC1
org.apache.cocoon:cocoon-xml-api:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-impl:1.0.0-RC1
org.apache.cocoon:cocoon-xml-impl:1.0.0-RC1
org.apache.cocoon:cocoon-pipeline-components:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-api:1.0.0-RC1
org.apache.cocoon:cocoon-thread-api:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-impl:1.0.0-RC1
org.apache.cocoon:cocoon-sitemap-components:1.0.0-RC1
org.apache.cocoon:cocoon-xml-resolver:1.0.0-RC1
org.apache.cocoon:cocoon-store-impl:1.0.0-RC1
org.apache.cocoon:cocoon-thread-impl:1.0.0-RC1
org.apache.cocoon:cocoon-core:2.2.0-RC1
Subproject: Servlet-Service (jar)
-
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M2
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M2
Blocks (jar)
org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC1
org.apache.cocoon:cocoon-template-impl:1.0.0-RC1
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC1
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC1
org.apache.cocoon:cocoon-auth-api:1.0.0-RC1
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC1
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC1
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC1
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC1
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC1
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC1
org.apache.cocoon:cocoon-html-impl:1.0.0-RC1
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC1
org.apache.cocoon:cocoon-forms-impl:1.0.0-M3
org.apache.cocoon:cocoon-ajax-impl:1.0.0-M3
Maven plugins, archetypes and related (jar)
---
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1
org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC1
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC1
POM artifacts
-
org.apache.cocoon.cocoon:4
org.apache.cocoon:cocoon-core-modules:4
org.apache.cocoon:cocoon-blocks-modules:4
org.apache.cocoon:cocoon-tools-modules:4
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[vote][results] Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
I count
4 binding +1 votes
1 non-binding +1 vote
This means that the vote passed. I will push the proposed artifacts to the
official Maven repository and draft an announcment mail ASAP.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
Leszek Gawron wrote:
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Please cast your votes, whether we want to make the proposed artifacts
official releases and publish them to the Maven repository. The vote is
open for 72 hours.
+1
+1 .. and hoping for fast final release in central maven repo :)
This one will go to the *central* Maven repository too.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: Please cast your votes, whether we want to make the proposed artifacts official releases and publish them to the Maven repository. The vote is open for 72 hours. +1 +1 .. and hoping for fast final release in central maven repo :) -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > > Please cast your votes, whether we want to make the proposed artifacts > official releases and publish them to the Maven repository. The vote is > open for 72 hours. > +1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iD8DBQFF5U1eLNdJvZjjVZARAlaaAJ9BWAjaQ4eWqnoTyOCqAQr8p/6c1ACg7UfR ZO9kNwIqOVyrkCw+sB+DFm0= =FMw/ -END PGP SIGNATURE-
Re: [Vote] Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
Carsten Ziegeler wrote:
I added [vote] to the subject of this thread.
Reinhard Poetz wrote:
Please cast your votes, whether we want to make the proposed artifacts official
releases and publish them to the Maven repository. The vote is open for 72 hours.
+1
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [Vote] Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
Carsten Ziegeler napisał(a): I added [vote] to the subject of this thread. Reinhard Poetz wrote: Please cast your votes, whether we want to make the proposed artifacts official releases and publish them to the Maven repository. The vote is open for 72 hours. +1 I've tested it with my toys and everything works good. Although non-binding, here is my: +1. It's really good to see all them released, thanks Reinhard! -- Grzegorz Kossakowski
Re:[Vote] Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
I added [vote] to the subject of this thread. Reinhard Poetz wrote: > > Please cast your votes, whether we want to make the proposed artifacts > official > releases and publish them to the Maven repository. The vote is open for 72 > hours. > +1 Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Releasing from trunk: Cocoon 2.2 M3, Cocoon Configuration & others
It's time for another series of module releases, see the list of all 41
artifacts below. SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/.
Note that this time there are two artifacts that are proposed to be "final
releases". See "Subproject: Configuration" below.
The proposed binary and pom artifacts are available at
http://people.apache.org/builds/cocoon/ for your tests. Find instructions about
how you can test in seperate mail. Report your finding to that thread and use
this one for voting only. Thanks!
Cocoon 2.2: Core modules
-
cocoon-core-2.2.0-M3.jar
cocoon-core-2.2.0-M3-tests.jar
cocoon-xml-api-1.0.0-M1.jar
cocoon-xml-impl-1.0.0-M1.jar
cocoon-thread-api-1.0.0-M1.jar
cocoon-thread-impl-1.0.0-M1.jar
cocoon-util-1.0.0-M1.jar
cocoon-store-impl-1.0.0-M1.jar
cocoon-xml-resolver-1.0.0-M1.jar
cocoon-pipeline-api-1.0.0-M1.jar
cocoon-pipeline-impl-1.0.0-M1.jar
cocoon-pipeline-impl-1.0.0-M1-tests.jar
cocoon-sitemap-api-1.0.0-M1.jar
cocoon-sitemap-impl-1.0.0-M1.jar
cocoon-pipeline-components-1.0.0-M1.jar
cocoon-sitemap-components-1.0.0-M1.jar
cocoon-flowscript-impl-1.0.0-M2.jar
Cocoon 2.2: Blocks
-
cocoon-template-impl-1.0.0-M3.jar
cocoon-ajax-impl-1.0.0-M2.jar
cocoon-forms-impl-1.0.0-M2.jar
cocoon-batik-impl-1.0.0-M1.jar
cocoon-captcha-impl-1.0.0-M1.jar
cocoon-fop-impl-1.0.0-M1.jar
cocoon-mail-impl-1.0.0-M1.jar
cocoon-html-impl-1.0.0-M1.jar
cocoon-databases-hsqldb-server-1.0.0-M1.jar
cocoon-databases-hsqldb-client-1.0.0-M1.jar
cocoon-databases-mocks-1.0.0-M1.jar
cocoon-databases-impl-1.0.0-M1.jar
cocoon-auth-api-1.0.0-M1.jar
cocoon-auth-impl-1.0.0-M1.jar
cocoon-linkrewriter-impl-1.0.0-M1.jar
POM artifacts
-
cocoon-3.pom
cocoon-blocks-modules-3.pom
cocoon-core-modules-3.pom
Maven 2 Archetypes
-
cocoon-22-archetype-block-1.0.0-M5.jar
cocoon-22-archetype-webapp-1.0.0-M2.jar
Subproject: Configuration
-
cocoon-configuration-api-1.0.0.jar
cocoon-spring-configurator-1.0.0.jar
Subproject: Servlet-service
-
cocoon-servlet-service-impl-1.0.0-M1.jar
cocoon-servlet-service-components-1.0.0-M1.jar
Please cast your votes, whether we want to make the proposed artifacts official
releases and publish them to the Maven repository. The vote is open for 72 hours.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Reinhard Poetz wrote: > > Thanks. > > When I ran the tests the last time, they run through but this was before > Carsten > has started with his refactorings of the portal-impl block. > > I guess that he will clean up the tests too after he has finished his work. > Sure :) I started converting all the portal components from Avalon to Spring which will take some time. I forgot to update the base test case class. But that's fixed now. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
The build runs through again, at least for me. I tested with an
empty local repository. Could others please verify?
Consistently fails with
Strange :-(
Can you run the tests from within your IDE and find out what exactly
is failing?
Well it fails from maven so I'd rather give you test output generated by
maven. It is, by the way, can be found in
/cocoon/blocks/cocoon-portal/cocoon-portal-impl/target/surefire-reports.
Thanks.
When I ran the tests the last time, they run through but this was before Carsten
has started with his refactorings of the portal-impl block.
I guess that he will clean up the tests too after he has finished his work.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Reinhard Poetz wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: The build runs through again, at least for me. I tested with an empty local repository. Could others please verify? Consistently fails with Strange :-( Can you run the tests from within your IDE and find out what exactly is failing? Well it fails from maven so I'd rather give you test output generated by maven. It is, by the way, can be found in /cocoon/blocks/cocoon-portal/cocoon-portal-impl/target/surefire-reports. Here is snippet from it: --- Test set: org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase --- Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.536 sec <<< FAILURE! testEventReceiver(org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase) Time elapsed: 0.409 sec <<< ERROR! org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.portal.PortalService; nested exception is org.apache.avalon.framework.service.ServiceException: Component with 'org.apache.cocoon.portal.layout.renderer.RendererMap' is not defined in this service manager. (Key='AvalonServiceManager') Caused by: org.apache.avalon.framework.service.ServiceException: Component with 'org.apache.cocoon.portal.layout.renderer.RendererMap' is not defined in this service manager. (Key='AvalonServiceManager') at org.apache.cocoon.core.container.spring.avalon.AvalonServiceManager.lookup(AvalonServiceManager.java:57) at org.apache.cocoon.portal.impl.PortalServiceImpl.service(PortalServiceImpl.java:126) at org.apache.avalon.framework.container.ContainerUtil.service(ContainerUtil.java:143) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:224) at .. Complete file attached. Vadim --- Test set: org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase --- Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.536 sec <<< FAILURE! testEventReceiver(org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase) Time elapsed: 0.409 sec <<< ERROR! org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.portal.PortalService; nested exception is org.apache.avalon.framework.service.ServiceException: Component with 'org.apache.cocoon.portal.layout.renderer.RendererMap' is not defined in this service manager. (Key='AvalonServiceManager') Caused by: org.apache.avalon.framework.service.ServiceException: Component with 'org.apache.cocoon.portal.layout.renderer.RendererMap' is not defined in this service manager. (Key='AvalonServiceManager') at org.apache.cocoon.core.container.spring.avalon.AvalonServiceManager.lookup(AvalonServiceManager.java:57) at org.apache.cocoon.portal.impl.PortalServiceImpl.service(PortalServiceImpl.java:126) at org.apache.avalon.framework.container.ContainerUtil.service(ContainerUtil.java:143) at org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:224) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) at org.apache.cocoon.AbstractTestCase.initBeanFactory(AbstractTestCase.java:150) at org.apache.cocoon.core.container.ContainerTestCase.initBeanFactory(ContainerTestCase.java:334) at org.apache.cocoon.AbstractTestCase.setUp(AbstractTestCase.java:91) at org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:165) at org.apac
Re: Releasing from trunk
Simone Gianni wrote:
Reinhard Poetz wrote:
I've been working on the release for the past couple of hours. As it's
late here, I need some sleep. Unfortunatly this means that the trunk
is broken ATM. I will continue later today and fix all poms.
Sorry for any inconveniences.
Just a quick question. Why don't we use version ranges instead of fixed
version numbers in our internal pom dependencies?
While using a version range on an external dependency can be dangerous
'cause we are not sure they will respect versioning rules, we could use
them for internal dependencies and save a lot of work when the version
of a single component changes and avoid having to cleanup the
repository, rebuild everything, change the version in the pom, re-clean
the repository and so on. Also because when we will have "1.0.0" version
of a block published on public repository it will be a real pain to
debug which components are still pointing to instead than to the new
1.0.1 version.
Is there some hidden problem with version ranges?
Simone, I have to admit that I don't understand the problem that will be solved
by version ranges.
Let's assume that you use cocoon-forms-1.0.0.jar which has a dependency on
cocoon-core-2.2.0.jar. After a while we release cocoon-core-2.2.1.jar. If you
upgrade your own project descriptor to the new version, Maven will use this
instead of the version set in cocoon-forms.
What would be different with version ranges?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
The build runs through again, at least for me. I tested with an
empty local repository. Could others please verify?
Consistently fails with
---
T E S T S
---
Running org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase
log4j:WARN No appenders could be found for logger
(org.springframework.core.CollectionFactory).
log4j:WARN Please initialize the log4j system properly.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.6 sec
<<< FAILURE!
Strange :-(
Can you run the tests from within your IDE and find out what exactly is failing?
Do others see this behaviour too?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
On Tue, Feb 13, 2007 at 12:00:19PM +0100, Simone Gianni wrote: > Reinhard Poetz wrote: > > > > I've been working on the release for the past couple of hours. As it's > > late here, I need some sleep. Unfortunatly this means that the trunk > > is broken ATM. I will continue later today and fix all poms. > > > > Sorry for any inconveniences. > > > Just a quick question. Why don't we use version ranges instead of fixed > version numbers in our internal pom dependencies? > > While using a version range on an external dependency can be dangerous > 'cause we are not sure they will respect versioning rules, we could use > them for internal dependencies and save a lot of work when the version > of a single component changes and avoid having to cleanup the > repository, rebuild everything, change the version in the pom, re-clean > the repository and so on. Also because when we will have "1.0.0" version > of a block published on public repository it will be a real pain to > debug which components are still pointing to instead than to the new > 1.0.1 version. AFAIK version requirements like '1.0.0' are so-called soft requirements, a recommendation. A hard requirement looks like '[1.0.0]'. See this page for more info: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution A soft version requirement of '1.0' will use 1.0.1 if available I think. Fred
Re: Releasing from trunk
Reinhard Poetz wrote: > > I've been working on the release for the past couple of hours. As it's > late here, I need some sleep. Unfortunatly this means that the trunk > is broken ATM. I will continue later today and fix all poms. > > Sorry for any inconveniences. > Just a quick question. Why don't we use version ranges instead of fixed version numbers in our internal pom dependencies? While using a version range on an external dependency can be dangerous 'cause we are not sure they will respect versioning rules, we could use them for internal dependencies and save a lot of work when the version of a single component changes and avoid having to cleanup the repository, rebuild everything, change the version in the pom, re-clean the repository and so on. Also because when we will have "1.0.0" version of a block published on public repository it will be a real pain to debug which components are still pointing to instead than to the new 1.0.1 version. Is there some hidden problem with version ranges? Simone
Re: Releasing from trunk
Reinhard Poetz wrote: The build runs through again, at least for me. I tested with an empty local repository. Could others please verify? Consistently fails with --- T E S T S --- Running org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase log4j:WARN No appenders could be found for logger (org.springframework.core.CollectionFactory). log4j:WARN Please initialize the log4j system properly. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. [DEBUG] XMLizer: Default parser is 'org.apache.excalibur.xml.sax.SAXParser'. Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.6 sec <<< FAILURE! Vadim
Re: Releasing from trunk
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
I've been working on the release for the past couple of hours. As it's
late here, I need some sleep. Unfortunatly this means that the trunk is
broken ATM. I will continue later today and fix all poms.
Sorry for any inconveniences.
So far I've created the release artifacts for core, servlet-service and
configuration. Some blocks and the archetypes will follow soon.
The build runs through again, at least for me. I tested with an empty local
repository. Could others please verify?
Great work Reinhard!!
I works for me as well.
Now, as we have final release artifacts for the configuration stuff we
should reference these final releases instead of snapshots, so the all
dependencies to "cocoon-configuration-api" and
"cocoon-spring-configurator" should point to version 1.0.0.
wasn't sure about this. But make sense to me. Though we have to wait until they
are available at the Maven central repository.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Reinhard Poetz wrote: > Reinhard Poetz wrote: >> I've been working on the release for the past couple of hours. As it's >> late here, I need some sleep. Unfortunatly this means that the trunk is >> broken ATM. I will continue later today and fix all poms. >> >> Sorry for any inconveniences. > > So far I've created the release artifacts for core, servlet-service and > configuration. Some blocks and the archetypes will follow soon. > > The build runs through again, at least for me. I tested with an empty local > repository. Could others please verify? > Great work Reinhard!! I works for me as well. Now, as we have final release artifacts for the configuration stuff we should reference these final releases instead of snapshots, so the all dependencies to "cocoon-configuration-api" and "cocoon-spring-configurator" should point to version 1.0.0. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Reinhard Poetz wrote:
I've been working on the release for the past couple of hours. As it's
late here, I need some sleep. Unfortunatly this means that the trunk is
broken ATM. I will continue later today and fix all poms.
Sorry for any inconveniences.
So far I've created the release artifacts for core, servlet-service and
configuration. Some blocks and the archetypes will follow soon.
The build runs through again, at least for me. I tested with an empty local
repository. Could others please verify?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
I've been working on the release for the past couple of hours. As it's late
here, I need some sleep. Unfortunatly this means that the trunk is broken ATM. I
will continue later today and fix all poms.
Sorry for any inconveniences.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Releasing from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 9 Feb 2007, Jorg Heymans wrote: Date: Fri, 09 Feb 2007 22:19:22 +0100 From: Jorg Heymans <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Releasing from trunk Giacomo Pati wrote: It's the default of Continuum to build a modularized M2 project in isolation (see build command in the Continuum Config Page). We build our modularized M2 project as a hole and do not have the problem you mentioned above. It is just a matter how you define your project in Continuum. You mean you configured it as a shell project ? Not sure i can follow you here. We're talking about CI 1.0.3 right ? No, no, I've removed the "--non-recursive" flag from the invocation command and only have the root pom be built. Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (GNU/Linux) iD8DBQFFzZqoLNdJvZjjVZARAj0KAKCLxdI4QiNpaPi1BLHr8VNbD9oPQwCcDdzV azhHyhb3TsV7+NXBFviNC9o= =RzoG -END PGP SIGNATURE-
Re: Releasing from trunk
Carsten Ziegeler wrote: Perhaps David can help as he did the conversion for Cocoon. FYI David is working on this. As soon as he's ready i'll reroll the release (from trunk) and call the vote. Jorg
Re: Releasing from trunk
Giacomo Pati wrote: It's the default of Continuum to build a modularized M2 project in isolation (see build command in the Continuum Config Page). We build our modularized M2 project as a hole and do not have the problem you mentioned above. It is just a matter how you define your project in Continuum. You mean you configured it as a shell project ? Not sure i can follow you here. We're talking about CI 1.0.3 right ? Jorg
Re: Releasing from trunk
Hi, On 9 Feb 2007, at 16:15, Simone Gianni wrote: As soon as someone else gives it's +1, I'll work on it on Sunday. As discussed offline: a huge +1! Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Sourcesense: http://www.sourcesense.com/
Re: Releasing from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 7 Feb 2007, Jorg Heymans wrote: Date: Wed, 07 Feb 2007 20:03:46 +0100 From: Jorg Heymans <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Releasing from trunk Vadim Gritsenko wrote: > Continuum was stopped because I started to flatten the POM hierarchy in > trunk. This will hopefully save me a lot of time during the release > process. Do I understand it correctly - it should be turned off to simplify release process? Sounds Ok to me if that's the case. Continuum is a nice-to-have but by no means a requirement for any release of cocoon. The general idea, as i'm sure i don't have to explain, is only to have something flag when someone checks in code that breaks the build. -o0o- At the time, Continuum seemed like an obvious choice for CI, mainly because it was built by the maven developers and promised/claimed good integration with m2. However now that we've learned the tricks and quirks of building an m2 project i can honestly not say anymore if Continuum is the best tool for the job ATM. The problem with Continuum is that it doesn't build your project as a whole anymore, but rather the modules in relative isolation. The fact that it doesn't pick up pom changes and barfs when you do module refactoring (move, adding, removing, changing name etc) makes it more of a nuisance than anything else. A CI system is no good if you have to take care of it each time you change the structure of your system. I've heard good things about Hudson [1], which has a more traditional approach in that it does a build from the top level (eg mvn clean install from the root) each time. This is more time and resource consuming but ATM more accurate for us. However its native m2 support is still in its infancy [2]. It's the default of Continuum to build a modularized M2 project in isolation (see build command in the Continuum Config Page). We build our modularized M2 project as a hole and do not have the problem you mentioned above. It is just a matter how you define your project in Continuum. Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (GNU/Linux) iD8DBQFFzKRPLNdJvZjjVZARAseuAKCmCMP8qedya9qop25PYtUN1utl8ACfRl1d lJpcgaAX1Fp4LTn+h90h0y4= =Z48G -END PGP SIGNATURE-
Re: Releasing from trunk
Hi, On 9 Feb 2007, at 15:04, Giacomo Pati wrote: I absolutely support Carsten here. Addmittedly we only have a few core devs that use 2.2 for their daily work and business. But tell me, Andrew, who else is using/testing 2.2 in real world environments, you? Hang on, that's my point - not enough others using it! I'd love to get a 2.2. site into a real world environment, but I'm still working on documenting the how and the why before I get to that. It's something that's _really_ missing so far. We more or less have still the same test cases as with 2.1. Are those the test cases from 2.1 that we have to disable? :-( I know, I know, if it's an itch for me I should scratch it! Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Sourcesense: http://www.sourcesense.com/
Re: Releasing from trunk
Vadim Gritsenko wrote: > Simone Gianni wrote: >> Vadim Gritsenko wrote: >>> Make it easy to try it and people will come. >>> >> I do totally agree. As showed at cocoon-gt, I have a IzPack based >> installer that already delivers a cocoon dist, with a small gui with >> three buttons (start server, stop server, open welcome page) that start >> and stop an embedded jetty loading the dist .war file. >> It's a matter of a couple of hours to commit it and have it deliver the >> samples-dist. >> > If you can somehow coerce maven :) into building this binary demo in > the cocoon-dist-samples module [1], that sounds really great. It just > might perform the role of a binary download [2]. > > [1] > http://svn.apache.org/repos/asf/cocoon/trunk/dists/cocoon-dist-samples/ > [2] http://cocoon.apache.org/mirror.cgi > IzPack has an ant task to generate the installer, and they report on their site [1] that it has been "fixed for calling the IzPack ANT task from Maven", so it should be possible to incorporate it in a profile of a dist, so that calling that profile would generate also the monolithic installer. As soon as someone else gives it's +1, I'll work on it on Sunday. Simone [1] http://www.izforge.com/izpack/history?s=maven
Re: Releasing from trunk
Vadim Gritsenko wrote: > Simone Gianni wrote: >> Vadim Gritsenko wrote: >>> Make it easy to try it and people will come. >>> >> I do totally agree. As showed at cocoon-gt, I have a IzPack based >> installer that already delivers a cocoon dist, with a small gui with >> three buttons (start server, stop server, open welcome page) that start >> and stop an embedded jetty loading the dist .war file. >> It's a matter of a couple of hours to commit it and have it deliver the >> samples-dist. >> > If you can somehow coerce maven :) into building this binary demo in > the cocoon-dist-samples module [1], that sounds really great. It just > might perform the role of a binary download [2]. > > [1] > http://svn.apache.org/repos/asf/cocoon/trunk/dists/cocoon-dist-samples/ > [2] http://cocoon.apache.org/mirror.cgi > IzPack has an ant task to generate the installer, and they report on their site [1] that it has been "fixed for calling the IzPack ANT task from Maven", so it should be possible to incorporate it in a profile of a dist, so that calling that profile would generate also the monolithic installer. As soon as someone else gives it's +1, I'll work on it on Sunday. Simone [1] http://www.izforge.com/izpack/history?s=maven
Re: Releasing from trunk
Simone Gianni wrote: Vadim Gritsenko wrote: Make it easy to try it and people will come. I do totally agree. As showed at cocoon-gt, I have a IzPack based installer that already delivers a cocoon dist, with a small gui with three buttons (start server, stop server, open welcome page) that start and stop an embedded jetty loading the dist .war file. Also other apache projects are starting to use it to deliver demo or final binary builds, like apacheds for example. It's a matter of a couple of hours to commit it and have it deliver the samples-dist. Can't think of anything simpler than this and doable in a short time ATM. The only drawback I see is that WAR file of a complete cocoon dist is very big, but we can clearly specify that this happens only because it's a binary complete build quick and easy to setup, and that once they will start working with maven etc.. they will not have to do those big massive download, cause maven will take care of downloading only the needed jars and only once. Let me know if you think this could ease users to test the 2.2, I can do it in the weekend. If you can somehow coerce maven :) into building this binary demo in the cocoon-dist-samples module [1], that sounds really great. It just might perform the role of a binary download [2]. What do y'all think? Vadim [1] http://svn.apache.org/repos/asf/cocoon/trunk/dists/cocoon-dist-samples/ [2] http://cocoon.apache.org/mirror.cgi
Re: Releasing from trunk
Giacomo Pati wrote: Andrew Savory wrote: And yes, I'm putting my money where my mouth is and trying to use 2.2 to build a site ;-) I absolutely support Carsten here. Addmittedly we only have a few core devs that use 2.2 for their daily work and business. But tell me, Andrew, who else is using/testing 2.2 in real world environments, you? I'm in the process of building an application on Cocoon 2.2 snapshot, circa 2006/12/11. I'm yet to catch up with latest changes on trunk - new modules are introduced almost daily. Fact that some test cases fail (happened yesterday) and (if you skip tests) complete build fails too make it a bit harder to keep on the edge. Vadim
Re: Releasing from trunk
Vadim Gritsenko wrote: > Make it easy to try it and people will come. > I do totally agree. As showed at cocoon-gt, I have a IzPack based installer that already delivers a cocoon dist, with a small gui with three buttons (start server, stop server, open welcome page) that start and stop an embedded jetty loading the dist .war file. Also other apache projects are starting to use it to deliver demo or final binary builds, like apacheds for example. It's a matter of a couple of hours to commit it and have it deliver the samples-dist. Can't think of anything simpler than this and doable in a short time ATM. The only drawback I see is that WAR file of a complete cocoon dist is very big, but we can clearly specify that this happens only because it's a binary complete build quick and easy to setup, and that once they will start working with maven etc.. they will not have to do those big massive download, cause maven will take care of downloading only the needed jars and only once. Let me know if you think this could ease users to test the 2.2, I can do it in the weekend. Simone
Re: Releasing from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 7 Feb 2007, Carsten Ziegeler wrote: Date: Wed, 07 Feb 2007 11:21:32 +0100 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Releasing from trunk Andrew Savory wrote: Hi, Not wishing to spread FUD and rain on the parade, but ... I think 2.2 is *massively* less tested than 2.1.x. The main reason 2.1.x goes out with not much testing is because it's been used in production by a very large number of people. How many are actually using 2.2 in production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess at most < 10 sites? I'd love to see 2.2 out the door and more people using it, but I'd also hate to see people's first experience of 2.2 be a buggy one. Given that we're still seeing changes enough to kill Cruisecontrol, I'd suggest an 'M' is more suitable than an 'RC'. And yes, I'm putting my money where my mouth is and trying to use 2.2 to build a site ;-) Great :) We need to get a 2.2 out; imho it is more important to have something out after so many years than having a 115% bug free version. In addition, there is no guarantee that releasing a milestone will bring us more users testing, more documentation etc. And I personally doubt that people will start trying a milestone release. I absolutely support Carsten here. Addmittedly we only have a few core devs that use 2.2 for their daily work and business. But tell me, Andrew, who else is using/testing 2.2 in real world environments, you? We more or less have still the same test cases as with 2.1. And what will be the exit criteria? When do we have enough confidence (if it is really missing today) that we are stable enough for switching from milestone to rc? We only have indicators and feelings. I think that the current code base is stable and the work we are doing with is a proof for this (for me). Some do have confidence in 2.2 because it's being used by them for real world projects! On the other hand, a RC does not mean bug free - it means stable from the api and implementation pov. If we would be sure that it's bug free we could release a final right way. Yes, we had several changes in the last days/weeks, but doing a RC gives ourselves the responsibility to not change these things until we have a final version out (or create a branch). So, in short: a RC is an indication to *everyone* that this is the a stable version from the api pov and that we think (or hope if you like) that this version is stable as well. It's more likely that people will try out an RC than a milestone. So if we get feedback back at all, this will happen for an RC but never for a milestone. +1 Ciao and thanks - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (GNU/Linux) iD8DBQFFzI1+LNdJvZjjVZARAvobAKCpKWARj9+145orxZ5H20963/ztHACeMVOI 26HnUJ2BE/kTFZ/QrRgGqjI= =wNuu -END PGP SIGNATURE-
Re: Releasing from trunk
Vadim Gritsenko wrote: #!/bin/bash rm -fr ~/.m2/repository Or: rm -rf ~/.m2/repository/org/apache/cocoon possibly yes. I'm still debating the usefulness of downloading everything new each time. It was useful back in the days where existing poms were updated, they seem to have this under control now. cd src/cocoon-trunk svn update mvn clean install > ~/cocoon-build.log 2>&1 if [ "$?" -ne "0" ]; then some_mail_foo_to_send_the_file_to_dev@ It's actually simple... MAILFILE=/home/vadim/cocoon-test-mail-`date '+%Y%m%d'`.txt echo "From: Vadim Gritsenko <[EMAIL PROTECTED]>" > $MAILFILE echo Subject: Cocoon-2.1.X Tests Failure `date '+%m/%d/%y'` >> $MAILFILE ... mail -t dev@cocoon.apache.org < $MAILFILE fi Thanks! Jorg
Re: Releasing from trunk
Jorg Heymans wrote: So for me, currently, the best solution ATM for CI would be to cron something like this: #!/bin/bash rm -fr ~/.m2/repository Or: rm -rf ~/.m2/repository/org/apache/cocoon cd src/cocoon-trunk svn update mvn clean install > ~/cocoon-build.log 2>&1 if [ "$?" -ne "0" ]; then some_mail_foo_to_send_the_file_to_dev@ It's actually simple... MAILFILE=/home/vadim/cocoon-test-mail-`date '+%Y%m%d'`.txt echo "From: Vadim Gritsenko <[EMAIL PROTECTED]>" > $MAILFILE echo Subject: Cocoon-2.1.X Tests Failure `date '+%m/%d/%y'` >> $MAILFILE ... mail -t dev@cocoon.apache.org < $MAILFILE fi Vadim, didn't you have something similar running for Cocoon 2.1 ? I did but it was largely ignored. :) hm. :( I also had clover reports on top. Vadim Regards Jorg [1] https://hudson.dev.java.net/ [2] http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html
Re: Releasing from trunk
Vadim Gritsenko wrote: Continuum was stopped because I started to flatten the POM hierarchy in trunk. This will hopefully save me a lot of time during the release process. Do I understand it correctly - it should be turned off to simplify release process? Sounds Ok to me if that's the case. Continuum is a nice-to-have but by no means a requirement for any release of cocoon. The general idea, as i'm sure i don't have to explain, is only to have something flag when someone checks in code that breaks the build. -o0o- At the time, Continuum seemed like an obvious choice for CI, mainly because it was built by the maven developers and promised/claimed good integration with m2. However now that we've learned the tricks and quirks of building an m2 project i can honestly not say anymore if Continuum is the best tool for the job ATM. The problem with Continuum is that it doesn't build your project as a whole anymore, but rather the modules in relative isolation. The fact that it doesn't pick up pom changes and barfs when you do module refactoring (move, adding, removing, changing name etc) makes it more of a nuisance than anything else. A CI system is no good if you have to take care of it each time you change the structure of your system. I've heard good things about Hudson [1], which has a more traditional approach in that it does a build from the top level (eg mvn clean install from the root) each time. This is more time and resource consuming but ATM more accurate for us. However its native m2 support is still in its infancy [2]. So for me, currently, the best solution ATM for CI would be to cron something like this: #!/bin/bash rm -fr ~/.m2/repository cd src/cocoon-trunk svn update mvn clean install > ~/cocoon-build.log 2>&1 if [ "$?" -ne "0" ]; then some_mail_foo_to_send_the_file_to_dev@ fi Vadim, didn't you have something similar running for Cocoon 2.1 ? Regards Jorg [1] https://hudson.dev.java.net/ [2] http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html
Re: Releasing from trunk
Carsten Ziegeler wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: Anyways, I'm a little bit clueless how to continue. Some of us say, let's call it RC, some say no as "things are missing". Since writing more mails would take longer than releasing another series of core milestone releases, I will release cocoon-core-2.2 as M3. :) It would be great, if we could at least release the configurator as final (as proposed). +1 here. Vadim
Re: Releasing from trunk
Reinhard Poetz wrote: Vadim Gritsenko wrote: Regardless of download presence, at the very least there should be a 2.2 site set up and running. http://cocoon.apache.org/2.2/ IMNSHO we don't have http://cocoon.apache.org/2.2/ anymore. Information about the core will be available at http://cocoon.apache.org/core-modules/core/2.2/ (see http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/ to get an idea of the big picture) Actually... About the big picture, I'm not sure I'm getting it. The current site structure is: / - Cocoon Project (PMC) site /1.x - Cocoon 1.x site /2.0 - ... /2.1 So from the POV of top level site, what is Cocoon 2.2 - where should it be in the list of "Projects". Is it "Cocoon NG" project? Does it mean there is no "root" path for Cocoon 2.2 docs - they are all scattered around PMC site? (I'm assuming here that /core-modules is not the only path element used in 2.2 docs). Where would (radically different, hypothetical) Cocoon 3.0 go if Cocoon 2.2 will take unversioned http://cocoon.apache.org/core-modules/ space? Keep in mind that copy of 2.2.Last docs will have to be accessible after 3.0 goes gold. Vadim
Re: Releasing from trunk
Reinhard Poetz wrote: > Carsten Ziegeler wrote: > > [...] > >> Anyways, I'm a little bit clueless how to continue. Some of us say, >> let's call it RC, some say no as "things are missing". > > Since writing more mails would take longer than releasing another series of > core > milestone releases, I will release cocoon-core-2.2 as M3. > :) It would be great, if we could at least release the configurator as final (as proposed). Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
It is a bit different for 2.2 though: there were no "real"
downloadable release yet,
And maybe there will never be one. Don't know. There doesn't seem to
be much energy in this community to provide it - especially if you use
Maven 2 you don't need it.
If using maven 2, might be, yes.
Regardless of download presence, at the very least there should be a 2.2
site set up and running.
http://cocoon.apache.org/2.2/
IMNSHO we don't have http://cocoon.apache.org/2.2/ anymore. Information about
the core will be available at http://cocoon.apache.org/core-modules/core/2.2/
(see http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/ to get an
idea of the big picture)
Next, announcements has to be sent out. It should go out to [EMAIL PROTECTED]
as well.
http://marc.theaimsgroup.com/?l=xml-apache-announce&m=105161222423468
How else people would know about new release if it is not mentioned
anywhere?
ok
so there is really no easy way to download 2.2 and give it a spin on
existing 2.1 project.
That's not true. What's missing is a guide how to do it. Technically
it shouldn't be too difficult.
It's not difficult if you know it all. It is not trivial for users,
especially with no Spring exposure.
* have CC working and not failing over,
Continuum was stopped because I started to flatten the POM hierarchy
in trunk. This will hopefully save me a lot of time during the release
process.
Do I understand it correctly - it should be turned off to simplify
release process? Sounds Ok to me if that's the case.
No. I removed about 7 modules from our repository (see the commit messages with
a "flatten pom hierarchy" description) and Continuum still tried to build them.
It has to be reconfigured but anybody hasn't had time to do it yet.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Hi, On 7 Feb 2007, at 14:01, Carsten Ziegeler wrote: Now, I will ask the open question right away: who will work on the missing parts? FX: TUMBLEWEED Gosh, no rush of people to say "I will!" ;-) On 7 Feb 2007, at 14:49, Reinhard Poetz wrote: From my experience over the last months, I'd say that there isn't much energy for actual work, especially nobody wants to work on the documentation. If you have noclue what to write, you could start to write a migration guide. Or look at the existing documentation and continue with the docs migration. FYI, I'm working on just such a document now, outlining what's changed, how to migrate, all the relevant stuff for the end user. I'm still trying to figure out what's best practice for things like application-specific sitemaps, where to put things etc. I hope to get a first draft in Daisy by the end of the weekend. But if we get as much snow as predicted, it may be delayed by igloo-building :-) Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Sourcesense: http://www.sourcesense.com/
Re: Releasing from trunk
Reinhard Poetz wrote: Vadim Gritsenko wrote: It is a bit different for 2.2 though: there were no "real" downloadable release yet, And maybe there will never be one. Don't know. There doesn't seem to be much energy in this community to provide it - especially if you use Maven 2 you don't need it. If using maven 2, might be, yes. Regardless of download presence, at the very least there should be a 2.2 site set up and running. http://cocoon.apache.org/2.2/ Next, announcements has to be sent out. It should go out to [EMAIL PROTECTED] as well. http://marc.theaimsgroup.com/?l=xml-apache-announce&m=105161222423468 How else people would know about new release if it is not mentioned anywhere? so there is really no easy way to download 2.2 and give it a spin on existing 2.1 project. That's not true. What's missing is a guide how to do it. Technically it shouldn't be too difficult. It's not difficult if you know it all. It is not trivial for users, especially with no Spring exposure. * have CC working and not failing over, Continuum was stopped because I started to flatten the POM hierarchy in trunk. This will hopefully save me a lot of time during the release process. Do I understand it correctly - it should be turned off to simplify release process? Sounds Ok to me if that's the case. Vadim
Re: Releasing from trunk
Carsten Ziegeler wrote:
[...]
Anyways, I'm a little bit clueless how to continue. Some of us say,
let's call it RC, some say no as "things are missing".
Since writing more mails would take longer than releasing another series of core
milestone releases, I will release cocoon-core-2.2 as M3.
Now, I will ask
the open question right away: who will work on the missing parts?
From my experience over the last months, I'd say that there isn't much energy
for actual work, especially nobody wants to work on the documentation.
If you have noclue what to write, you could start to write a migration guide. Or
look at the existing documentation and continue with the docs migration.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
[...]
We need to get a 2.2 out; imho it is more important to have something
out after so many years than having a 115% bug free version.
You are missing a point. It's not about a bug free version. It is about
a version which seen more than like 4 hours of testing after major surgery.
In addition, there is no guarantee that releasing a milestone will bring
us more users testing, more documentation etc. And I personally doubt
that people will start trying a milestone release.
Counterpoint:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843
They are not even trying, they are using it in production. It is a bit
different for 2.2 though: there were no "real" downloadable release yet,
And maybe there will never be one. Don't know. There doesn't seem to be much
energy in this community to provide it - especially if you use Maven 2 you don't
need it.
so there is really no easy way to download 2.2 and give it a spin on
existing 2.1 project.
That's not true. What's missing is a guide how to do it. Technically it
shouldn't be too difficult.
High entry point would hamper wider adoption of 2.2, not the label on
its release.
And what will be the exit criteria? When do we have enough confidence
(if it is really missing today) that we are stable enough for switching
from milestone to rc? We only have indicators and feelings. I think that
the current code base is stable and the work we are doing with is a
proof for this (for me).
When there is a consensus in the community that version is ready for RC
or Final release. Given the responses so far, you already can see that
to reach consensus we'd have to:
* have some more testing done (not 4h or 1d as now),
* have unit tests working,
* have CC working and not failing over,
Continuum was stopped because I started to flatten the POM hierarchy in trunk.
This will hopefully save me a lot of time during the release process.
[...]
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Vadim Gritsenko wrote: > You are missing a point. It's not about a bug free version. It is about a > version which seen more than like 4 hours of testing after major surgery. > Sorry, but that's not fair. There were no code or api changes to the core in the last weeks (apart from bug fixes). There were some structural changes and continued work on the servlet-fw, but that is not part of the things we want to release as rcs. > >> In addition, there is no guarantee that releasing a milestone will bring >> us more users testing, more documentation etc. And I personally doubt >> that people will start trying a milestone release. > > Counterpoint: >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843 > > They are not even trying, they are using it in production. It is a bit > different > for 2.2 though: there were no "real" downloadable release yet, so there is > really no easy way to download 2.2 and give it a spin on existing 2.1 project. > > High entry point would hamper wider adoption of 2.2, not the label on its > release. Agreed. > When there is a consensus in the community that version is ready for RC or > Final > release. Given the responses so far, you already can see that to reach > consensus > we'd have to: > >* have some more testing done (not 4h or 1d as now), >* have unit tests working, >* have CC working and not failing over, > Unit tests work. > Do you mean to say you can't stop doing major refactoring and start polishing > unless it bears RC badge? What happened to good old-fashioned discipline and > self control? :) "self control?" - what's that? :) I meant that marking something RC has more or less the same effect as a code freeze. So it "prevents" from changing and should streamline all effort into getting that thing out of the door. Anyways, I'm a little bit clueless how to continue. Some of us say, let's call it RC, some say no as "things are missing". Now, I will ask the open question right away: who will work on the missing parts? Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Reinhard Poetz wrote: What we need now is more people who use/try it and in this sense it doesn't help to ship more milestone releases. Make it easy to try it and people will come. http://cocoon.apache.org/mirror.cgi http://cocoon.apache.org/2.2/ Contrast and compare with 2.1 milestones: http://archive.apache.org/dist/cocoon/SOURCES/ http://cocoon.apache.org/2.1/changes.html#N11DF5 There were *no* single 2.2M release shipped yet. Vadim
Re: Releasing from trunk
Carsten Ziegeler wrote: Andrew Savory wrote: Hi, Not wishing to spread FUD and rain on the parade, but ... I think 2.2 is *massively* less tested than 2.1.x. The main reason 2.1.x goes out with not much testing is because it's been used in production by a very large number of people. How many are actually using 2.2 in production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess at most < 10 sites? I'd love to see 2.2 out the door and more people using it, but I'd also hate to see people's first experience of 2.2 be a buggy one. Given that we're still seeing changes enough to kill Cruisecontrol, I'd suggest an 'M' is more suitable than an 'RC'. +1 And yes, I'm putting my money where my mouth is and trying to use 2.2 to build a site ;-) Great :) We need to get a 2.2 out; imho it is more important to have something out after so many years than having a 115% bug free version. You are missing a point. It's not about a bug free version. It is about a version which seen more than like 4 hours of testing after major surgery. In addition, there is no guarantee that releasing a milestone will bring us more users testing, more documentation etc. And I personally doubt that people will start trying a milestone release. Counterpoint: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843 They are not even trying, they are using it in production. It is a bit different for 2.2 though: there were no "real" downloadable release yet, so there is really no easy way to download 2.2 and give it a spin on existing 2.1 project. High entry point would hamper wider adoption of 2.2, not the label on its release. And what will be the exit criteria? When do we have enough confidence (if it is really missing today) that we are stable enough for switching from milestone to rc? We only have indicators and feelings. I think that the current code base is stable and the work we are doing with is a proof for this (for me). When there is a consensus in the community that version is ready for RC or Final release. Given the responses so far, you already can see that to reach consensus we'd have to: * have some more testing done (not 4h or 1d as now), * have unit tests working, * have CC working and not failing over, On the other hand, a RC does not mean bug free - it means stable from the api and implementation pov. If we would be sure that it's bug free we could release a final right way. Agree. Yes, we had several changes in the last days/weeks, but doing a RC gives ourselves the responsibility to not change these things until we have a final version out (or create a branch). Do you mean to say you can't stop doing major refactoring and start polishing unless it bears RC badge? What happened to good old-fashioned discipline and self control? :) Vadim So, in short: a RC is an indication to *everyone* that this is the a stable version from the api pov and that we think (or hope if you like) that this version is stable as well. It's more likely that people will try out an RC than a milestone. So if we get feedback back at all, this will happen for an RC but never for a milestone. Carsten
Re: Releasing from trunk
Andrew Savory wrote: > Hi, > > Not wishing to spread FUD and rain on the parade, but ... I think 2.2 > is *massively* less tested than 2.1.x. The main reason 2.1.x goes out > with not much testing is because it's been used in production by a > very large number of people. How many are actually using 2.2 in > production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess > at most < 10 sites? > > I'd love to see 2.2 out the door and more people using it, but I'd > also hate to see people's first experience of 2.2 be a buggy one. > > Given that we're still seeing changes enough to kill Cruisecontrol, > I'd suggest an 'M' is more suitable than an 'RC'. > > And yes, I'm putting my money where my mouth is and trying to use 2.2 > to build a site ;-) > Great :) We need to get a 2.2 out; imho it is more important to have something out after so many years than having a 115% bug free version. In addition, there is no guarantee that releasing a milestone will bring us more users testing, more documentation etc. And I personally doubt that people will start trying a milestone release. And what will be the exit criteria? When do we have enough confidence (if it is really missing today) that we are stable enough for switching from milestone to rc? We only have indicators and feelings. I think that the current code base is stable and the work we are doing with is a proof for this (for me). On the other hand, a RC does not mean bug free - it means stable from the api and implementation pov. If we would be sure that it's bug free we could release a final right way. Yes, we had several changes in the last days/weeks, but doing a RC gives ourselves the responsibility to not change these things until we have a final version out (or create a branch). So, in short: a RC is an indication to *everyone* that this is the a stable version from the api pov and that we think (or hope if you like) that this version is stable as well. It's more likely that people will try out an RC than a milestone. So if we get feedback back at all, this will happen for an RC but never for a milestone. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
Re: Releasing from trunk
Hi, On 7 Feb 2007, at 07:13, Carsten Ziegeler wrote: I really doubt that most of the code for final releases (or rc) is tested better than what we currently have in trunk. We do releases for 2.1.x without real tests for most of the code base. We rely on user experience/tests. The version from trunk is used by several of us already in production, several people have tried it out and it seems that most of the problems have been fixed. So I really think that this qualifies for an RC release. Not wishing to spread FUD and rain on the parade, but ... I think 2.2 is *massively* less tested than 2.1.x. The main reason 2.1.x goes out with not much testing is because it's been used in production by a very large number of people. How many are actually using 2.2 in production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess at most < 10 sites? I'd love to see 2.2 out the door and more people using it, but I'd also hate to see people's first experience of 2.2 be a buggy one. Given that we're still seeing changes enough to kill Cruisecontrol, I'd suggest an 'M' is more suitable than an 'RC'. And yes, I'm putting my money where my mouth is and trying to use 2.2 to build a site ;-) Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Sourcesense: http://www.sourcesense.com/
Re: Releasing from trunk
Reinhard Poetz skrev: Carsten Ziegeler wrote: Vadim Gritsenko wrote: RC has a meaning of "release candidate", which to most people means "well tested almost production quality code". Going through recent commits I noticed a lot of refactoring, new code, untested code, and so on. This hardly qualifies as RC material. IMHO, it should be labeled as M(n+1). -1 on RC since code is not went through enough testing yet. I really doubt that most of the code for final releases (or rc) is tested better than what we currently have in trunk. We do releases for 2.1.x without real tests for most of the code base. We rely on user experience/tests. The version from trunk is used by several of us already in production, several people have tried it out and it seems that most of the problems have been fixed. So I really think that this qualifies for an RC release. Just wanted to write something similar. What we need now is more people who use/try it and in this sense it doesn't help to ship more milestone releases. I also think that it is an *important signal to us*: 2.2 is complete, the contracts are stable and they can't be changed. The rest of the work is polishing and writing documentation. Yes guys, after almost 3 1/2 years we will ship something that isn't a patch release!!! +1 /Daniel
Re: Releasing from trunk
On 2/7/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: ...The version from trunk is used by several of us already in production, several people have tried it out and it seems that most of the problems have been fixed. So I really think that this qualifies for an RC release... Excuse the silly question (I haven't followed 2.2 at all in the last months), but are the automated tests of the core parts working? If there are enough automated tests for people working on 2.2 to have confidence in it, a release candidate is certainly a good option. -Bertrand
Re: Releasing from trunk
Reinhard Poetz wrote:
I also think that it is an *important signal to us*: 2.2 is complete,
the contracts are stable and they can't be changed
One thing to add: As Cocoon is modularized now, we can and _will_ have different
release cycles for our modules, e.g. if we think it's useful we can release
Cocoon Forms every month and if we change contracts there we can release 2.0.
All this can happen without releasing core or other blocks again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
RC has a meaning of "release candidate", which to most people means "well tested
almost production quality code". Going through recent commits I noticed a lot of
refactoring, new code, untested code, and so on. This hardly qualifies as RC
material.
IMHO, it should be labeled as M(n+1). -1 on RC since code is not went through
enough testing yet.
I really doubt that most of the code for final releases (or rc) is
tested better than what we currently have in trunk. We do releases for
2.1.x without real tests for most of the code base. We rely on user
experience/tests. The version from trunk is used by several of us
already in production, several people have tried it out and it seems
that most of the problems have been fixed. So I really think that this
qualifies for an RC release.
Just wanted to write something similar. What we need now is more people who
use/try it and in this sense it doesn't help to ship more milestone releases.
I also think that it is an *important signal to us*: 2.2 is complete, the
contracts are stable and they can't be changed. The rest of the work is
polishing and writing documentation.
Yes guys, after almost 3 1/2 years we will ship something that isn't a patch
release!!!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
