cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Renaming Corona to Cocoon 3.0 and infrastructure
Date Mon, 18 Aug 2008 15:04:32 GMT
Grzegorz Kossakowski wrote:
> Sylvain Wallez pisze:
>> I can't say what problems there are _now_ since I don't build Cocoon 
>> anymore. Hopefully it works now, and I was referring to the past: 
>> when the move to Maven was started, the 2.2 build was mostly broken 
>> for months, which drained an incredible amount of energy away from 
>> the project, either because people got discouraged by this broken 
>> build (e.g. me), or because they invested their volunteer time in 
>> understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon.
>> I'm glad it seems to work now, but the amount of energy needed to 
>> setup and maintain this build system (remember, it's _just_ a build 
>> system) has been astronomical.
> I've been working with Maven (mainly when working with Cocoon) for 
> more than year and I can agree on main point of Maven critics that 
> Maven is flawed.
> My personal opinion is that basic ideas behind Maven are correct but 
> implementation is totally broken. Or at least it was at the beginning 
> because now, thanks to many eye balls, it seems to improve from 
> release to release.
> I was wondering many times if there is any other choice for us. Given 
> the amount energy we've put into mavenization process any switch is 
> impossible so such discussion could be only theoretical. Still I would 
> enjoy reading about some alternatives because this could put my (and 
> probably others) thinking into right direction thus, eventually 
> improving our existing infrastructure.

This isn't theoretical at all. Use Ant+Ivy ( 
and you have something that doesn't rely on undocumented declarative 
black magic (the various plugins you add to your pom.xml), doesn't 
require you to write your own plugins (or tasks as they're called in 
Ant) and gives you line-precise error reporting when something goes wrong.

> There is one statement that I don't agree: Maven is not just a build 
> system. If it was only a build system I would be the first one to 
> propose dropping Maven completely because of its implementation. For 
> me, Maven is the whole ecosystem which consists of good practices when 
> it comes to your project's structure, Maven repository (the killer 
> feature IMHO) and integration with so many systems acting around basic 
> build process.

Ivy for your artifacts management. It does it well, and can use Maven 
repositories. I've been using it happily for more than 2 years now on 
rather big projects (after having banged my head on Maven).

> What I would prefer is to take a lesson from our past experience but 
> still focus on the future. I strongly believe that we have reached 
> this stage when people can happily focus on developing Cocoon and not 
> on developing Cocoon's infrastructure thus I would like to invite all 
> old-timers to join our forces and provide the best of Cocoon 
> experience ever. I strongly believe we have all foundations needed for 
> that now.

And this leads to another question, which Reinhard outlined in his 
latest blog post, and Stefano did years ago: what's the purpose of 
Cocoon in today's technology landscape? It used to be a great "you can 
do everything with it" solution, but these days are over. There are some 
very nice webapp component frameworks like Wicket or GWT, there are ESBs 
that do pipelined transformations like Mule or ServiceMix, and XML is no 
more the only mainstream interchange language with the success of JSON 
and the emergence of binary formats like Thrift or Google Buffers.

Cocoon therefore has to be rethought as a toolbox for those domains 
where it has no equivalent, and find new domains where it can innovate, 
and Corona (or whatever its name) certainly goes in the right direction. 
Pipelines are among the existing distinctive features of Cocoon, and 
also REST-ish pattern matching although many frameworks are now 

>> It's very nice to see people using 2.2, but I have the impression 
>> that most of the 2.2-related questions are related to maven-isms, 
>> artifacts, poms, etc. Without wanting to sound harsh, I'm wondering 
>> whether this community has learned to live over time with some sort 
>> of chronic disease, and is so used to it now that it doesn't even 
>> realize that life could be easier without it.
> Most of these questions come from the confusion about splitting up 
> Cocoon into smaller pieces. And even more questions come from the fact 
> that people starting with 2.2 are still trying to build it themselves 
> because that was done in 2.1. If you use released versions then you 
> will have no problem with dependencies, missing artifacts, etc.
> When you checkout trunk and try to build it then I would say that it 
> should be no surprise that sometimes you get into troubles, right?

The build should fail only if there are some bugs in Cocoon's code 
(compilation issues or failed tests) or if some artifacts are missing 
from your cache and remote repositories aren't available (BTW this what 
just happened to me: there's a compilation failure in cocoon-core).

> I would really like to know what kind of chronic disease you see 
> Sylvain. I don't deny there might be one so if you would have shared 
> your observations with rest community we could start to think about 
> improving it in the future.

By "chronic disease", I was referring to Maven. And it's not specific to 
Cocoon, but to many other projects. Maven has brought one new brillant 
idea to the Java world, which is artifact repositories (note though that 
Linux repositories have existed for a very long time). But using Maven 
requires to adhere to the whole thing: repository management, which is 
good, but also a declarative under-documented build system. And Maven is 
also self-updating, which is a nice idea on paper but means the buid is 
not repeatable since you don't know what is used to build your system.

This works very well for small projects that have few dependencies and 
produce only few standard artifacts like jar files, and this explains 
its success in the opensource community where it is very often in this 
case, and also why it has been so painful for Cocoon which is a quite 
complex beast.

>> Note that I said "could" and not "would" since ultimately the 
>> people-that-do decide what they prefer. And yes I'm a retired 
>> old-timer here, but I still care for this community where I learned 
>> so much.
> For me it would be interesting to see if one of "retired old-timers" 
> could try to spend some time on playing with trunk just to gather some 
> experience. Certainly, such "external" audit by some of the most 
> honored members of this community would be a blessing experience only 
> if it would allow to bring closer our stances.

I'm afraid I don't have the free cycles for this.


Sylvain Wallez -

View raw message