cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Mon, 05 Dec 2005 10:27:46 GMT
Le 4 déc. 05, à 11:27, Sylvain Wallez a écrit :

> Bertrand Delacretaz wrote:
>> ....In the meantime, maybe offering an embeddable version of your 
>> "dynamic pipelines" thing would be a great help in getting more 
>> people to use the unique things that Cocoon has to offer. But it's a 
>> much smaller vision than yours ;-)
> Yes, but that can be the first step: define this pipeline API and the 
> minimal amount of components for it to be usable (a parser, an XSLT 
> and XInclude transformer and a bunch of serializers), and build on it. 
> Doing it that way can also ensure this pipeline API is kept 
> independent from the surrounding front-end, be it flowscript, Spring 
> webflow or an ESB engine....

I like this as an initial vision for Cocoon 3.0: take a small part of 
what we have that is really unique (XML processing pipelines), and 
repackage it as a small POJO-based thing that people can use in 
different contexts.

I've thought a bit more about your RT, and I think the single most 
important thing in ensuring a future for Cocoon and the community is

   ** We need to play better with others **

We have some great things (Pipelines, Forms, Flow as an innovative way 
of glueing java components together, Continuations) but to use them 
people have to commit to Cocoon as a whole. It's a big decision, and 
considering the amount of (justified) uncertainty about Java's future 
as an application language, I think less people will make this decision 
in the next year.

I think being able to deliver our good things in smaller embeddable 
packages would make a big difference: people can then pick what they 
need from Cocoon yet continue working with the tools that they're used 

If the overall Cocoon offering is useful to them, they might switch 
completely later on, but at first they'd just use parts of Cocoon 
within their existing environment, and start to love them because 
they're useful to them, not because we told them to love these things 
(which is what we're trying to do currently, with little success).

As a nice side effect, such a structure would *force* clean modularity 
on us.

So my conclusion is: the mutation that we need is towards embeddable 
POJOs, which allow our unique stuff to be reused elsewhere, in small 

The dream of having the Java applications world switch to Cocoon is 
over, yet we have many cool things to offer - this is an opportunity to 
broaden the use of these cool things.


View raw message