I think I'm noticing something here. There are several people who
are not (yet) major contributors to roller asking for a maven build
since they find the current ant build a major impediment to
understanding the project and working on it, and there are several
people who are thoroughly familiar with the current ant build who are
saying they are familiar with the current ant build and it works.
Two of the people who want maven have offered to create the maven
build (and one has done so within the limits of not moving anything).
This goes along with my general observation that ant is good if you
want to keep your project private and unrelated to other software or
new contributors and maven is good if you want your project to have
good relations with other projects, both as a consumer of
dependencies such as spec jars and as a supplier of parts such as
roller to the geronimo roller plugin.
One of the biggest reasons I haven't found the time to propose a
patch for the new security stuff (which I consider seriously flawed)
is the pain of trying to understand how parts of the project are
interrelated. This is just not a problem with a reasonably well laid
out maven project.
thanks
david jencks
On Feb 11, 2008, at 9:03 PM, Phillip Rhodes wrote:
Woonsan Ko wrote:
Dear Dave,
- Making the build process easy
- Providing a uniform build system
- Providing quality project information
- Providing guidelines for best practices development
- Allowing transparent migration to new features
Most of that sounds like marketing gobbledygook to me. Nice sounding
words, but no real substance. How is M2 easier than Ant exactly? Is
the Maven build more "uniform" than the Ant build? Only if you mean
uniform across different projects, but ya know, that just doesn't
strike me as a big deal. Most projects use a roughly common
set of target names and it's usually pretty easy to figure out
what means what when beginning with a new project, in my experience.
OTOH, Maven is over-engineered to the point that doing something
as simple as changing the compiler source level means pasting
a huge blob of XML into a pom.xml file:
<http://maven.apache.org/plugins/maven-compiler-plugin/howto.html>
Whereas with Ant it's as simple as changing a line like this:
<javac source="1.4" ... />
to
<javac source="1.6" ... />
just to use one example.
All of that said, we are actually using a slightly different build
system when we build Roller as part of OpenQabal. But it's not
Maven, it's just our own common Ant build file. We think it gives
us most of the advantages of Maven while leaving out
the stuff we find to be fairly superfluous (like the output
of maven site:site or whatever it is) and keeping the nice
simple ant way of doing things.
The main advantages we find with using Ivy and this build
environment is
that it does make managing dependencies easier (same as Maven in this
regard) and it lets us manage things in a project / sub-project
hierarchy (again, same as Maven). So we can, for example publish
Roller
artifacts (like the war file(s)) to a repository where they can
then be
pulled in as declared dependencies of our "main" project for
inclusion in the EAR. But all of this makes sense for OpenQabal, it
doesn't really mean anything for Roller per-se, or I would have
considered proposing to Dave to adopt this environment for Roller.
But
as he says, the existing system works, so why mess with it? :-)
TTYL,
--
Phillip Rhodes
Chief Architect - OpenQabal
https://openqabal.dev.java.net
