cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD Éric <eburg...@free.fr>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Mon, 05 Dec 2005 12:01:16 GMT
Daniel Fagerstrom wrote:

> 
> What do you think about moving block dependecy handling from block.xml
> to pom.xml? It means reduced flexibilty as block dependencies becomes
> direct instead of indirect as in the current schema. OTH it reduce
> complexity and fullfills our current use cases. If we need indirect
> dependencies we can add it later. There would be a need to give the
> dependencies POM unique ids that can be used in the block protocol and
> we also need a way to be able to mark a dependency as "extension", any
> idea if this would be possible?
> 
> Hmm, while that would be nice at some point I think that it currently
> would be enough to have a block aware variant of the war pluggin. That
> fetch and install all needed blocks in the webapp one i developing.
> Maybe wiring.xml could even be expressed as a POM for this pluggin?
> 

2 wonderfull ideas !

Before you wrote that, daniel, i was very frightened by the new 'hot' block
framework because of
 * the new kind of descriptor,
 * all the new jar introduced (osgi, knopflerfish: even if don't know if
there are really related to this, it's part of the cocoon new face)
 * the fact that blocks are not regular jar (even if i don't know what it
means it's frightening for a java developer :-)

After 2 years using cocoon i just can't explain clearly how to build an
application over cocoon-core and a few blocks staticaly. You should do
something with block management for sure, but IMHO hot deployment should
not be a priority. It just seems like adding an unecessary new layer of
complexity (i know that you think this is simpler :-).

Since a few week i'm just about to see the end of the tunnel thanks to maven
2 and its archetypes, and i'm full of hope again because it's simple and
clear. My application is now constructed by maven, all the jar, ant, jelly,
tools disappear from my repository. It just a lot easier to synchonise my
app my a new cocoon snapshot.

It took me only a few days to understand the process and even contribute to
maven. Just to tell you that i felt very far away from the vertical
learning slope of cocoon. I'm quite fed up with cocoon and it's complexity,
and a few people in my team already drop it. It's just sad because
everybody gave a lot of time on this.

Maven 2.0 is the next big thing in java tools. And you took a really good
choice here. It would be a pain if users, used to maven (and they will be
more and more), had to learn another dependency management system.

IMHO, the reason of this complexity is that cocoon has always been thought
in terms of flexibility instead of usability and simplicity, constraints
instead of conventions. I really think that the kind of refactor that
occurs between maven 1 and 2 is a model of what has to be done for cocoon. 

So please (poor user request) define first a clean static build process with
well defined dependencies (concern 99% of users) before thinking of hot
deployment stuff. This build process could be defined for cocoon 2.1.9
without redefining the block management nor the jar stucture. It would give
new users the possibility to fire a new cocoon project in 30s (how lucky !
it took me several month just to know how to build a minimal cocoon
webapp).

My 0.02€

Regards.


Mime
View raw message