Drew Farris wrote:
On Fri, Apr 2, 2010 at 8:23 AM, Enis Söztutar <enis....@gmail.com> wrote:
.Do we have any build-specific reason that cannot be done with ivy.
It can be done with ivy, but it's generally far more manageable to do
everything with maven because there is considerably less configuration
required. Less to configure, less to maintain.
+1 for exploring, can't wait to give it a whirl.
I'm -0, not going to say no, not encourage.
* I don't like how maven tells me what my layout should be, that I have
to separate java source from other artifacts, what the layout is, but,
well, its only a bit of IDE refactoring that will make patching painful
for some time, nothing important :)
* I don't like the way it makes decisions about how much to trust the
dependency metadata, which IMO are only hints, beliefs held by other
developers at their time of deployment, not facts that may actually be
valid.
* I really don't like the way it makes decisions about my build process,
that (at least when I played with it) couldn't come to terms with ideas
like my test JARS were in fact artifacts all of their own, things that
I'd like to sign and publish and then pull into RPMs that would then get
pushed out to VMs I asked the infrastructure for earlier.
Admittedly, that was a few years back, things may have changed, someone
may understand POM inheritance logic and there may be less need to write
ant build.xml files to choreograph m2 builds across sub projects -as we
ended up doing when I was involved in Axis2. However, because of that
experience, I'm not going to jump up at the opportunity to go anywhere
near Maven myself.
The dir renaming stuff is the troublespot. Move things around and all
the patches break, backporting gets complex. Don't move stuff around and
you come up against assumptions about directory layout "convention over
configuration" that are hard coded into other peoples .class files.
These are bugs, but you have decide what your plan for dealing with them is
1. accept that everyone else has agreed that the maven team's directory
layout is the one true structure for any java project, accept the
patch/backport costs and move things.
2. file bugs against all plugins that fail to meet your requirements,
hope they get fixed and/or start patching them yourself and having to
release your patched plugin JARs into a repository, that being how maven
pulls the plugins down...
Like I said, -0.
Now if you will excuse me, I have to track down why the JT on a virtual
cluster bring up under JUnit is accepting jobs but never completing them.
-Steve
