[VOTE] HADOOP-6671 - To use maven for hadoop common build

[Giridharan Kesavan <gk...@apache.org>]

I  would like call for a vote to created a development branch of common
trunk to work on mavenizing hadoop common.

-Giri

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Stack <st...@duboce.net>]

+1 for exploring.  HBase TRUNK is now mavenized.  Has kinks still but
its getting there.  Will see if can get some of the "experts" hanging
in hbase space to help out with this effort.
St.Ack

On Thu, Apr 1, 2010 at 7:34 PM, Chris Douglas <cd...@apache.org> wrote:
> +1 -C
>
> On Thursday, April 1, 2010, Giridharan Kesavan <gk...@apache.org> wrote:
>>
>> I  would like call for a vote to created a development branch of common
>> trunk to work on mavenizing hadoop common.
>>
>> -Giri
>>
>

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Chris Douglas <cd...@apache.org>]

+1 -C

On Thursday, April 1, 2010, Giridharan Kesavan <gk...@apache.org> wrote:
>
> I  would like call for a vote to created a development branch of common
> trunk to work on mavenizing hadoop common.
>
> -Giri
>

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Owen O'Malley <ow...@gmail.com>]

+1 for creating a branch for exploring moving to Maven.

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Steve Loughran <st...@apache.org>]

Drew Farris wrote:
> On Fri, Apr 2, 2010 at 8:23 AM, Enis Söztutar <en...@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

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Jay Booth <ja...@gmail.com>]

Maven could also give us a more robust "eclipse-files" target based off of
the dependencies as defined in pom.xml, and possibly
"assemble-projects-eclipse" and "assemble-projects-dist" targets which could
pull down into an eclipse workspace or a distribution directory that was all
wired together and ready to go, i.e., no more "webapps not in classpath" and
assorted other errors which are a product of the project split.

This is all doable with ant+ivy of course, or bash for that matter, but
maven's inherently plugged into a maven repo and source repo and has
conventions around defining your dependencies in one place and running
different targets based off of them, so it would likely be more maintainable
in the long run.

+1 for exploring

On Fri, Apr 2, 2010 at 11:04 AM, Drew Farris <dr...@gmail.com> wrote:

> On Fri, Apr 2, 2010 at 8:23 AM, Enis Söztutar <en...@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.
>

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Drew Farris <dr...@gmail.com>]

On Fri, Apr 2, 2010 at 8:23 AM, Enis Söztutar <en...@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.

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Enis Söztutar <en...@gmail.com>]

On 04/01/2010 09:09 PM, Giridharan Kesavan wrote:
> I  would like call for a vote to created a development branch of common
> trunk to work on mavenizing hadoop common.
>
> -Giri
>
>    
+1 for exploring, but my previous experience with Maven made me switch 
back to ant+ivy. Maven is great, but ant+ivy is far more customizable. 
Do we have any build-specific reason that cannot be done with ivy. One 
issue is pushing releases to maven repo, but again it can be done from ivy.

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

[Jakob Homan <jh...@yahoo-inc.com>]

+1 for the the exploration.  *If* it works as advertised, it'll be a 
great time saver.
Giridharan Kesavan wrote:
> I  would like call for a vote to created a development branch of common
> trunk to work on mavenizing hadoop common.
> 
> -Giri
>