Grzegorz Kossakowski wrote:
Sylvain Wallez pisze:
I can't say what problems there are _now_ since I don't build Cocoon
anymore. Hopefully it works now, and I was referring to the past:
when the move to Maven was started, the 2.2 build was mostly broken
for months, which drained an incredible amount of energy away from
the project, either because people got discouraged by this broken
build (e.g. me), or because they invested their volunteer time in
understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon.
I'm glad it seems to work now, but the amount of energy needed to
setup and maintain this build system (remember, it's _just_ a build
system) has been astronomical.
I've been working with Maven (mainly when working with Cocoon) for
more than year and I can agree on main point of Maven critics that
Maven is flawed.
My personal opinion is that basic ideas behind Maven are correct but
implementation is totally broken. Or at least it was at the beginning
because now, thanks to many eye balls, it seems to improve from
release to release.
I was wondering many times if there is any other choice for us. Given
the amount energy we've put into mavenization process any switch is
impossible so such discussion could be only theoretical. Still I would
enjoy reading about some alternatives because this could put my (and
probably others) thinking into right direction thus, eventually
improving our existing infrastructure.
This isn't theoretical at all. Use Ant+Ivy (http://ant.apache.org/ivy/)
and you have something that doesn't rely on undocumented declarative
black magic (the various plugins you add to your pom.xml), doesn't
require you to write your own plugins (or tasks as they're called in
Ant) and gives you line-precise error reporting when something goes wrong.
There is one statement that I don't agree: Maven is not just a build
system. If it was only a build system I would be the first one to
propose dropping Maven completely because of its implementation. For
me, Maven is the whole ecosystem which consists of good practices when
it comes to your project's structure, Maven repository (the killer
feature IMHO) and integration with so many systems acting around basic
build process.
Ivy for your artifacts management. It does it well, and can use Maven
repositories. I've been using it happily for more than 2 years now on
rather big projects (after having banged my head on Maven).
What I would prefer is to take a lesson from our past experience but
still focus on the future. I strongly believe that we have reached
this stage when people can happily focus on developing Cocoon and not
on developing Cocoon's infrastructure thus I would like to invite all
old-timers to join our forces and provide the best of Cocoon
experience ever. I strongly believe we have all foundations needed for
that now.
And this leads to another question, which Reinhard outlined in his
latest blog post, and Stefano did years ago: what's the purpose of
Cocoon in today's technology landscape? It used to be a great "you can
do everything with it" solution, but these days are over. There are some
very nice webapp component frameworks like Wicket or GWT, there are ESBs
that do pipelined transformations like Mule or ServiceMix, and XML is no
more the only mainstream interchange language with the success of JSON
and the emergence of binary formats like Thrift or Google Buffers.
Cocoon therefore has to be rethought as a toolbox for those domains
where it has no equivalent, and find new domains where it can innovate,
and Corona (or whatever its name) certainly goes in the right direction.
Pipelines are among the existing distinctive features of Cocoon, and
also REST-ish pattern matching although many frameworks are now
REST-friendly.
It's very nice to see people using 2.2, but I have the impression
that most of the 2.2-related questions are related to maven-isms,
artifacts, poms, etc. Without wanting to sound harsh, I'm wondering
whether this community has learned to live over time with some sort
of chronic disease, and is so used to it now that it doesn't even
realize that life could be easier without it.
Most of these questions come from the confusion about splitting up
Cocoon into smaller pieces. And even more questions come from the fact
that people starting with 2.2 are still trying to build it themselves
because that was done in 2.1. If you use released versions then you
will have no problem with dependencies, missing artifacts, etc.
When you checkout trunk and try to build it then I would say that it
should be no surprise that sometimes you get into troubles, right?
The build should fail only if there are some bugs in Cocoon's code
(compilation issues or failed tests) or if some artifacts are missing
from your cache and remote repositories aren't available (BTW this what
just happened to me: there's a compilation failure in cocoon-core).
I would really like to know what kind of chronic disease you see
Sylvain. I don't deny there might be one so if you would have shared
your observations with rest community we could start to think about
improving it in the future.
By "chronic disease", I was referring to Maven. And it's not specific to
Cocoon, but to many other projects. Maven has brought one new brillant
idea to the Java world, which is artifact repositories (note though that
Linux repositories have existed for a very long time). But using Maven
requires to adhere to the whole thing: repository management, which is
good, but also a declarative under-documented build system. And Maven is
also self-updating, which is a nice idea on paper but means the buid is
not repeatable since you don't know what is used to build your system.
This works very well for small projects that have few dependencies and
produce only few standard artifacts like jar files, and this explains
its success in the opensource community where it is very often in this
case, and also why it has been so painful for Cocoon which is a quite
complex beast.
Note that I said "could" and not "would" since ultimately the
people-that-do decide what they prefer. And yes I'm a retired
old-timer here, but I still care for this community where I learned
so much.
For me it would be interesting to see if one of "retired old-timers"
could try to spend some time on playing with trunk just to gather some
experience. Certainly, such "external" audit by some of the most
honored members of this community would be a blessing experience only
if it would allow to bring closer our stances.
I'm afraid I don't have the free cycles for this.
Sylvain
--
Sylvain Wallez - http://bluxte.net
