hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build
Date Tue, 06 Apr 2010 13:14:03 GMT
Drew Farris wrote:
> On Fri, Apr 2, 2010 at 8:23 AM, Enis Söztutar <enis.soz@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 

* 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.


View raw message