[
https://issues.apache.org/jira/browse/HADOOP-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070699#comment-13070699
]
Alejandro Abdelnur commented on HADOOP-6671:
--------------------------------------------
Hi Eric,
Thanks for testing it out and the feedback.
*Regarding the layout*
I've thought the layout you are describing only applies for RPM/DEB. I'll
update it accordingly.
*Regarding package assembly in package phase*
I agree the 'verify' phase is not the right place, still the problem I'm facing
is that as part of the TAR creation we need to do an antrun task before
assembly:single and an antrun task after assembly:single. This is needed to
preserve the symlinks of SOs both on copying and on taring (the assembly plugin
converts symlinks into copied files both on copy and on taring).
On solution for this would be to take the assembly work to a separate maven
module (common-distro) as I had earlier. As this module will not have other job
that creating the TAR (RPM/DEB) we can use intermediate phases.
The use of this module by the reactor (in the parent POM) would be in a
profile, so only if doing -Dtar, -Drpm or -Ddeb it would kick in.
*Regarding your tar profile paragraph*
The idea is that the hadoop-tar descriptor will be generic for
common/hdfs/mapred and any other downstream project that wants to use a similar
layout.
The Hadop-profile is a POM project, thus we cannot put the
assemblies/annotations in there. In addition, it would break things in Maven if
there are classes/resource in there as they would not be compiled as part of
the child module, not they could be added a dependencies. Thus, they are
separate modules (which eventually could be in a dev-support profile and
released independently if we don't want to build them as part of the normal
Hadoop build).
*Regarding the 'dev' directory*
I've struggled with the name for a bit, it was bin, maven now dev. I don't like
it very much either. patch-build seems a bit odd as well, how about dev-support?
*Regarding the forward porting of the RPM/DEB packaging*
My idea is to first to get developers in Maven first (thus this patch, followed
by HDFS and mapreduce mavenization).
And then continue with packaging, i.e. HADOOP-7411 would take care of the
RPM/DEB of common.
I was hoping I would get some help from you here.
Thoughts?
Thxs.
Alejandro
> 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-AA.patch, HADOOP-6671-AB.patch,
> 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-AA.sh, mvn-layout-AB.sh,
> 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
