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 ;-)
+1!
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/