cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Date Wed, 23 May 2007 19:00:01 GMT
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?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message