You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/08/27 14:52:37 UTC

Release Cocoon 2.2RC2

I plan to release Cocoon 2.2RC2 between Sept 19th and Sept 21st, provided that I 
have enough time to publish our new documentation before  because it doesn't 
help much if we release things without telling anybody about it ;-)

Does anybody have problems with a code freeze from 18th to 21st of September in 
trunk?

I plan to release following artifacts:

org.apache.cocoon:cocoon-core:2.2.0-RC2 (+ all submodules)
org.apache.cocoon:cocoon-configuration-api:1.0.1 *
org.apache.cocoon:cocoon-spring-configurator:1.0.1 *
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M3
org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M3
org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC2
org.apache.cocoon:cocoon-template-impl:1.0.0-RC2
org.apache.cocoon:cocoon-apples-impl:1.0.0-RC2
org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC2
org.apache.cocoon:cocoon-auth-api:1.0.0-RC2
org.apache.cocoon:cocoon-auth-impl:1.0.0-RC2
org.apache.cocoon:cocoon-batik-impl:1.0.0-RC2
org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC2
org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC2
org.apache.cocoon:cocoon-databases-impl:1.0.0-RC2
org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC2
org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC2
org.apache.cocoon:cocoon-fop-impl:1.0.0-RC2
org.apache.cocoon:cocoon-html-impl:1.0.0-RC2
org.apache.cocoon:cocoon-mail-impl:1.0.0-RC2
org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC2
org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC2
org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC2
org.apache.cocoon.cocoon:5
org.apache.cocoon:cocoon-core-modules:5
org.apache.cocoon:cocoon-blocks-modules:5
org.apache.cocoon:cocoon-tools-modules:5
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M2**
org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M2**
org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M2**

* if Carsten wasn't faster ;-)
** if necessary because of changes in core that make M1 unuseable together with 
cocoon-core-2.2.0-RC2.

                                      - o -

A note to Grek:

As part of the expression module documentation you write that you want to 
release 1.0.0-M1 of the expression modules. For the time being I'm against 
having seperate releases of cocoon-core sub modules but always release them as a 
whole, at least for now*. We adivce our users that they should only have 
dependencies on cocoon-core and not on one of its submodules.

Or do you see a particular value in a release of the expression modules that 
would  make it worth to make an exception from this rule?


* I will change my opinion if cocoon-core doesn't contain Java code anymore and 
everything is at its right place ...



-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Splitting and cleaning up cocoon-core

Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> * I will change my opinion if cocoon-core doesn't contain Java code
>> anymore and everything is at its right place ...
> 
> I've taking a look on this issue when working on GSoC and moving stuff around. Basically we have:
> 
>   * code that can be moved immediately because there is no problem with dependencies
> 
>   * code that has some very complicated dependencies like CocoonSourceResolver
> 
>   * code that itself does not have any problems with dependencies but its tests depend on code from
> cocoon-core like CocoonTestCase. We can get rid of CocoonTestCase reliably only switching from
> Avalon to Spring so our components become beans thus much more test-friendly.
> 
> We could think about spending some time on it at Hackathon, WDYT?

yes, we should come up with a task list. The actual work should happen aftwards 
because we shouldn't break Cocoon (too often) while so many people will be 
working on it.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: Release Cocoon 2.2RC2

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> 
> I plan to release Cocoon 2.2RC2 between Sept 19th and Sept 21st,
> provided that I have enough time to publish our new documentation
> before  because it doesn't help much if we release things without
> telling anybody about it ;-)

+10000!

In response to some Carsten e-mail I said that I was planning to take care of releasing in late
September. You were faster with concrete proposal I'm fine that you take care of it and I would like
to lend my hand if any help is needed.

> Does anybody have problems with a code freeze from 18th to 21st of
> September in trunk?
> 
> I plan to release following artifacts:
> 
> org.apache.cocoon:cocoon-core:2.2.0-RC2 (+ all submodules)
> org.apache.cocoon:cocoon-configuration-api:1.0.1 *
> org.apache.cocoon:cocoon-spring-configurator:1.0.1 *
> org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M3
> org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M3
> org.apache.cocoon:cocoon-flowscript-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-template-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-apples-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-linkrewriter-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-auth-api:1.0.0-RC2
> org.apache.cocoon:cocoon-auth-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-batik-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-captcha-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-mocks:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-hsqldb-client:1.0.0-RC2
> org.apache.cocoon:cocoon-databases-hsqldb-server:1.0.0-RC2
> org.apache.cocoon:cocoon-fop-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-html-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-mail-impl:1.0.0-RC2
> org.apache.cocoon:cocoon-22-archetype-block:1.0.0-RC2
> org.apache.cocoon:cocoon-22-archetype-block-plain:1.0.0-RC2
> org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-RC2
> org.apache.cocoon.cocoon:5
> org.apache.cocoon:cocoon-core-modules:5
> org.apache.cocoon:cocoon-blocks-modules:5
> org.apache.cocoon:cocoon-tools-modules:5
> org.apache.cocoon:cocoon-maven-plugin:1.0.0-M2**
> org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M2**
> org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M2**
> 
> * if Carsten wasn't faster ;-)
> ** if necessary because of changes in core that make M1 unuseable
> together with cocoon-core-2.2.0-RC2.
> 
>                                      - o -
> 
> A note to Grek:
> 
> As part of the expression module documentation you write that you want
> to release 1.0.0-M1 of the expression modules. For the time being I'm
> against having seperate releases of cocoon-core sub modules but always
> release them as a whole, at least for now*. We adivce our users that
> they should only have dependencies on cocoon-core and not on one of its
> submodules.
> 
> Or do you see a particular value in a release of the expression modules
> that would  make it worth to make an exception from this rule?

EL stuff is completely independent from rest of core, it has no dependencies on cocoon modules so
there is no problem with releasing it independently.

On the other hand, if you are going to release rest of Cocoon there is no point in releasing it few
days earlier. ;)

My long-term goal is to stabilize development of EL to such extent that we can switch to the
released dependencies even in Cocoon's core.

> * I will change my opinion if cocoon-core doesn't contain Java code
> anymore and everything is at its right place ...

I've taking a look on this issue when working on GSoC and moving stuff around. Basically we have:

  * code that can be moved immediately because there is no problem with dependencies

  * code that has some very complicated dependencies like CocoonSourceResolver

  * code that itself does not have any problems with dependencies but its tests depend on code from
cocoon-core like CocoonTestCase. We can get rid of CocoonTestCase reliably only switching from
Avalon to Spring so our components become beans thus much more test-friendly.

We could think about spending some time on it at Hackathon, WDYT?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: Release Cocoon 2.2RC2

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> 
> I plan to release following artifacts:
> 

<snip/>

> org.apache.cocoon:cocoon-servlet-service-components:1.0.0-M3
> org.apache.cocoon:cocoon-servlet-service-impl:1.0.0-M3

<snip/>

I thought that we are going to release RC1 of servlet-service stuff. At least, we have RC1-SNAPSHOT
versions in poms. Why plans have changed?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/