[
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 plugin.
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 fix.
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 POM.
> 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
