Am 13.01.10 23:33, schrieb Thorsten Scherler:
On 13/01/2010, at 17:01, Richard Frovarp wrote:
What direction should we take this project? Last summer we decided
after releasing 2.0.3 we would up our Java version from 1.4 to
something more modern. However, now 1.5 is no longer supported. I
would prefer moving to 1.6. WDOT?
+1
What is the status of 2.2? What work remains? Should we be focusing
our effort on completing that?
I am not sure but Andreas did that rewrite but always pointed out
that it still needs some much more helping hands. IMO cocoon 2.2
offers enough benefit to justify using it over 2.1 however seeing
cocoon 3 on the road to being really stable I am not sure if we
should not look into using that version and doing another rewrite. I
prefer wicket over cforms a million times and c3 gives you this
possibility.
Thorsten and I are currently working on a medium-sized Cocoon 2.2
project. After 9 months of development I think I got quite a good
overview of this version. My overall conclusion is that the benefits
don't justify putting the burden of a migration to our users.
Build process: Maven has some serious deficiencies. It is very
inflexible when it comes to executing non-standard functionality during
the build. If you're lucky you find an existing plug-in, but still end
up with huge chunks of configuration XML in your POM files. If you're
unlucky you have to write your own mojo (which is pretty
straightforward, fair enough). One of the most fundamental drawbacks is
that you can't have multiple versions of the same development branch
(e.g. 1.0-SNAPSHOT) in the same repository. So you have to duplicate the
whole local repository (including all 3rd-party libs) for each
development version, which is a PITA and somewhat neutralizes the
benefits. Another issue is that you can't include custom JARs (e.g.
patched versions of 3rd-party libs) in the build. You have to deploy
them into the local repository, which requires additions to the build
process like OS-specific wrappers (shell scripts etc).
Cocoon 2.2 consists of a very large number of blocks and subprojects.
During our project we noticed that some of the blocks have issues in
particular versions. Finally we ended up with a patchwork of different
versions of blocks which haven't been released as a tested unit,
combined with patched versions from our vendor branch. IMO the approach
of releasing independent versions of blocks should be reconsidered.
From my point of view the most valuable new feature is the
servlet-service framework. It takes pipeline modularization to a whole
new level. E.g. you can define a pipeline in a module and delegate
particular transformation steps, and even the serialization, to a
different module. I'm pretty certain that Lenya could benefit from this
feature. But I doubt that it is worth the migration to Cocoon 2.2.
Having said this this reminds me on an really old conversion I had
with Antonio that the best way to develop a new version would be to
start to outline the functionality and architecture of the new
version and AFTERWARDS to implement it.
Yes, this makes sense. I still think that the current Lenya 2.2
"experiment" was/is worth the effort because it helped me to get a
feeling for Cocoon 2.2 and evaluate it for Lenya and for other projects.
But, as Thorsten pointed out, we should start from scratch and do some
preliminary design work if we consider the migration again.
BTW, a colleague of mine developed another part of the application I
mentioned using OSGi. You'd need a hammer and chisel to remove him from
this platform. It would certainly still need some pioneer spirit to bet
on OSGi for a web application, but Sling is already doing it and if this
is still in the pipeline for Cocoon (pun intended) you can count me in.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
