hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luke Lu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-3003) Publish Yarn and MapReduce artifacts to Maven snapshot repository
Date Fri, 16 Sep 2011 06:31:12 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105895#comment-13105895

Luke Lu commented on MAPREDUCE-3003:

bq. #1 is far from ideal, it is an error prone hack

It's a hack to workaround an open issue of maven. But it's actually far less error prone than
the versions plugin (see below).

bq. Besides, this the pros you mention for this approach are easily doable using the version
plugin (as it is done today for all the non MR modules).

No, the pros of approach #1 cannot be duplicated with versions plugin. With approach #1, I
can define multiple profiles in settings.xml and easily switch select an arbitrary version
combination with custom profiles in a drop down menu in an IDE. And it works consistently
across *all* downstream projects, simultaneously. You can never do that with the versions

bq. #2 is the right way of doing things in Maven, it is easy, straight forward and any developer
familiar with Maven (or learning) will understand what is going on.

No, pom version handling is still an open issue in Maven (cf. MNG-624, MNG-2971). Do you know
how many versions:set command lines and in which directories, in order to change the project
version just for hadoop-common? Please actually try it before saying that it's easy. The versions
plugin is not an official maven plugin, it's a codehaus plugin to workaround the current indecision
of maven pom version resolution. It's one of those most unmaven like plugins that mutates
POM sources and doesn't work with profiles.

IMO, the current maven implementation (up to 3.x) is confused/conflated about dependency and
build specifications. It should really have the concept of *published* artifacts, where the
(parent) version is automatically baked, for coding signing, install and deploy.

bq. I was doing 'mvn install' from trunk/ today and the MR POMs are un-usable.

mvn install should install working (with versions interpolated) poms in your .m2 repository,
unless someone borked one of the pom.xmls in the recent flurry of commits, while I wasn't
looking :) Please show me an actual broken pom from .m2/repository. It should be trivial to

That said, I can overlook the inconvenience of approach #2 for my working environment and
adopt the versions plugin mostly because I don't want see the bogus warnings from maven 3.0.x
:). I'm not gonna -1 on approach 2, as long as versions:set only needs to be done once (instead
of multiple times in in different directories) to switch versions.


> Publish Yarn and MapReduce artifacts to Maven snapshot repository
> -----------------------------------------------------------------
>                 Key: MAPREDUCE-3003
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3003
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: build
>            Reporter: Tom White
>            Assignee: Tom White
>         Attachments: MAPREDUCE-3003-0.23.patch, MAPREDUCE-3003.patch, MAPREDUCE-3003.patch
> Currently this is failing since no distribution management section is defined in the
> https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Common-trunk-Commit/883/consoleFull

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message