cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Date Wed, 23 May 2007 19:28:59 GMT
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>  2) offer an alternative to Maven 2
>> Option one is clear and is nearly finsihed. My question is regarding 
>> to option 2: What do you expect, when you download Cocoon 2.2 in order 
>> to get your new Cocoon 2.2 project started?
>> Keep in mind that Cocoon 2.2 is split into a core and several blocks 
>> (template, forms, etc.). All of them are separate release artifacts 
>> and in contrast to Cocoon 2.1 they can and will be shipped as binaries 
>> again. (Note that I'm not talking about samples, that's something 
>> different.)
> To be honest I would not like to see option 2 implemented. I believe 
> that diversity is important but we must also be aware of the costs that 
> come along with more options.
> First, I really think that we should focus on the other things like 
> documenting, testing, polishing and releasing stuff we already have.
> Of course, if someone wants to put his effort into developing Ant 
> scripts I won't stop him, it's always better than not doing anything.
> The second argument is stronger in my opinion. Even though introducing 
> more options is usually not so difficult, we must remember that it's our 
> (as community) responsibility to maintain these more options for a long 
> time.
> More options means that possible refactorings and serious changes are 
> much more difficult to carry out and providing migration guides is also 
> much more troublesome because you hardly can assume something about 
> readers setup.
> I would not really like to see situation like I can't help someone on 
> the list only because I don't want to dig through his very own 
> Ant-driven setup.
> Now I really like situation with Cocoon 2.2 where I can say this: mate, 
> use archetypes for your blocks and for assembling your webapp and if you 
> encounter some problems/bugs just extract bits related to the problem 
> and send us an ad-hoc created block showing the problem. Then, I can 
> just write mvn cocoon:rcl and start helping this person being sure that 
> we both talk about the same thing and problem.
> Sounds encouraging, doesn't it? :-)
> To sum up, if you really want to put effort into it could it be assumed 
> as only temporary solution that aims to make it easier to migrate?
Hmm, no I don't think so :)
Personally, I really love maven 2 and it works very well for a lot of 
our projects. It makes sense to use it for developing cocoon itself, but 
we should not force everyone who wants to do a cocoon project to use 
maven 2. This ain't gonna work.

You're right that we should not maintain all possible different ways, 
but we spend a lot of energy into 2.2 to make it independent from m2. 
For example that's the reason why we extract blocks at runtime through 
cocoon itself and not at build time. So if someone wants to use 
something different than m2, all he has to do is to create a block. A 
block is just a jar with a special format. We have to document this 
format anyway and that's all we have to do for other build systems. 
Nothing more but also nothing less.
But as a proof that the docs are correct and our ideas work, we should 
just come up with one additional solution like an ant script. My idea is 
to put this script into the documentation and not into our svn. The 
script would act as a starting point.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message