Matthew Montgomery wrote:
Not a Maven fan myself, but I wonder if really the core issue being
referred to is a predictable project structure? Getting to know the ins
and outs of Roller development does mean learning about the build
structure and how things are laid out. Perhaps, to point is a Maven
build would be more "pick up and code?"
The "predictable project structure" part is one of the few legitimate
advantages I see to Maven ( I'm not even counting transitive dependency
management since you can do that with Ant+Ivy). If you see a project
is using Maven, you can make certain assumptions about how the source
is laid out, etc.
BUT... and maybe it's just me.. I just don't see
that being a big deal. I was able to grab the Roller source and get it
building and figure out how to work on stuff in Roller, with fairly
minimal effort. Not, it wasn't "no effort" but it was a one time
effort of maybe a couple of hours, if that. I mean, c'mon, most
projects (at least the ones I've encountered) use a batch of fairly
common idioms and names anyway. And to the extent that some don't, it's
usually fairly easy to mentally translate things.
eg, if you do
$> ant -projecthelp
and see targets like init, clean, compile, package
or clean, build, build-all, package
etc.
it's - IMO - relatively easy to figure out what you need to do to
build the project.
That said, the one thing that is nice is when the target dependencies
are all setup so that you can just do $> ant clean $FOO
where FOO means "the ultimate target that creates the final artifacts"
and all the in-between steps "just happen". As opposed to having
to explicitly do $> ant init gen-code compile package
or something like that.
TTYL,
--
Phillip Rhodes
Chief Architect - OpenQabal
https://openqabal.dev.java.net
