[
https://issues.apache.org/jira/browse/HADOOP-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067459#comment-13067459
]
Alejandro Abdelnur commented on HADOOP-6671:
--------------------------------------------
Do you mean having one assembly descriptor for TAR, one for DEB and one for
RPM; and then reusing them for common, hdfs and mapreduce? If so, this is
possible
(http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html).
And still you'd have a common-distro, an hdfs-distro and mapreduce-distro
module.
I'm OK with the profiles to decide with distro you want to build (TAR/RPM/DEB).
However, I'm not OK with wiring the assembly to the package phase. I've done
exactly this in the first version of the Mavenization I've posted. And (as
mentioned in my previous post) I've got into messy situations where lots of
plugins are bound to non-standard phases in a particular order to ensure things
fall in place.
I rather used standard phase bindings for building a distro. For example:
To build the TAR distro without documentation:
{code}
$ mvn clean package assembly:single
{code}
To build the TAR distro with documentation:
{code}
$ mvn clean package site assembly:single
{code}
To build RPM the *-Prpm* profile and to build Debian the *-Pdebian* profile.
For example:
{code}
$ mvn clean package site assembly:single -Prpm
{code}
And still, the open issue is how to invoke the antrun plugin in a custom
lifecycle with phases like 'pre-assembly', 'assembly' & 'post-assembly' to be
able to use the antrun plugin before and after to take care of symlinks and
call the RPM/DEB generation tools.
> To use maven for hadoop common builds
> -------------------------------------
>
> Key: HADOOP-6671
> URL: https://issues.apache.org/jira/browse/HADOOP-6671
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: build
> Affects Versions: 0.22.0
> Reporter: Giridharan Kesavan
> Assignee: Alejandro Abdelnur
> Attachments: HADOOP-6671-cross-project-HDFS.patch,
> HADOOP-6671-e.patch, HADOOP-6671-f.patch, HADOOP-6671-g.patch,
> HADOOP-6671-h.patch, HADOOP-6671-i.patch, HADOOP-6671-j.patch,
> HADOOP-6671-k.sh, HADOOP-6671-l.patch, HADOOP-6671-m.patch,
> HADOOP-6671-n.patch, HADOOP-6671-o.patch, HADOOP-6671-p.patch,
> HADOOP-6671-q.patch, HADOOP-6671.patch, HADOOP-6671b.patch,
> HADOOP-6671c.patch, HADOOP-6671d.patch, build.png, common-mvn-layout-i.sh,
> hadoop-commons-maven.patch, mvn-layout-e.sh, mvn-layout-f.sh,
> mvn-layout-k.sh, mvn-layout-l.sh, mvn-layout-m.sh, mvn-layout-n.sh,
> mvn-layout-o.sh, mvn-layout-p.sh, mvn-layout-q.sh, mvn-layout.sh,
> mvn-layout.sh, mvn-layout2.sh, mvn-layout2.sh
>
>
> We are now able to publish hadoop artifacts to the maven repo successfully [
> Hadoop-6382]
> Drawbacks with the current approach:
> * Use ivy for dependency management with ivy.xml
> * Use maven-ant-task for artifact publishing to the maven repository
> * pom files are not generated dynamically
> To address this I propose we use maven to build hadoop-common, which would
> help us to manage dependencies, publish artifacts and have one single xml
> file(POM) for dependency management and artifact publishing.
> I would like to have a branch created to work on mavenizing hadoop common.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
