Grzegorz, thanks for your reply.
On 9/26/2007 3:27 PM, Grzegorz Kossakowski wrote:
Lars Huttar pisze:
I appreciate the recommendation. I will be interested to look into
Cocoon 2.2.
However, production applications for our organization are running on
Cocoon. Can I justify the risk of using an alpha version of Cocoon for
production apps?
It's certainly not in alpha state, it has beta status for some time and there
are people having big
apps on top of 2.2.
OK. That's good to know.
I searched the Cocoon web sites as best I could, e.g.
http://cocoon.apache.org/2.1/plan/overview/roadmap.html, and JIRA
(http://issues.apache.org/jira/browse/COCOON?report=com.sourcelabs.jira.plugin.portlet.releases:releases-projecttab),
and could not find information about a beta release of 2.2.
You can search archives of this list for people sharing their experiences.
I see a lot of questions and bug reports about 2.2; but I suppose that's
to be expected from a mailing list.
Was there ever an announcement of 2.2RC1 being released? (I see a lot of
discussion about it on the dev list, up to July 2, but I don't see an
announcement.)
Is Cocoon 2.2 to be released soon? (I found a blog entry from Sylvain
from March 2005 saying "it's very likely that the pressure will grow for
a release in the coming months...")
That shows we are bad at informing about our work but this is really going to
change because we will
switch to new site publishing mechanisms that make it a hell easier to update
Cocoon site and keep
everything relevant.
The truth is that Reinhard Pötz is just about pushing Cocoon 2.2 RC2 and we are
seriously thinking
about releasing final 2.2 quite soon.
Also, does Cocoon 2.2 have sufficient documentation (both in general,
and regarding configuration handling)? Can you point me to documentation
on configuration handling?
I recommend to start with this[1] tutorial that will give you basic idea of
real blocks that 2.2
introduces. When it comes to configuration handling, there is no one big
cocoon.xconf file any more
and Cocoon's configuration is handled by Configuration[2] subproject
(completely separate from
Cocoon when it comes to dependencies). The most important part that makes real
work of handling of
configuration is Spring configurator[3].
Thanks to Spring Configurator you can alter any existing configuration file
(Spring bean definition)
by using properties following some conventions. When it comes to extension
points listing some other
component (datasources, custom Forms widgets and so on) Spring Configurator
offers very powerful
bean-map that allows to collect all beans implementing particular interface
dynamically so there is
no central point of configuration that would have to be altered when new
implementation arises.
HTH.
[1] http://cocoon.zones.apache.org/dev-docs/2.2/1159_1_1.html
[2]
http://cocoon.zones.apache.org/dev-docs/subprojects/configuration/configuration-api/1.0/1314_1_1.html
[3]
http://cocoon.zones.apache.org/dev-docs/subprojects/configuration/spring-configurator/1.0/1304_1_1.html
Thanks.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
