Re: Future directions

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