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.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
