hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6629) versions of dependencies should be specified in a single place
Date Fri, 12 Mar 2010 22:35:27 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844728#action_12844728

Doug Cutting commented on HADOOP-6629:

> Actually, there is a third copy that must also be handled in .eclipse_templates/.classpath.

That's addressed by HADOOP-6407, HDFS-1035 and MAPREDUCE-1592.

> Does it work with mvn-install and mvn-publish?

It does work with mvn-install.  I've tested this patch with mapreduce consuming the generated
pom.  But I'd like someone who really understands Ivy categories (Giri?) to look this patch
over, since I just hacked the categories to generate the right required dependencies in the
pom without fully understanding how the categories meant to work.

It seems we're not totally consistent in the three projects about inheriting dependencies
from common versus declaring them explicitly.  We can have common's pom not require log4j,
since hdfs and mapreduce already require log4j explicitly in their ivy.xml, and they both
block log4j's bad dependencies (as does every other project in the world that uses log4j).
 That works, but it doesn't quite feel right.  Maybe we're stuck with it until log4j fixes
its dependencies?

> versions of dependencies should be specified in a single place
> --------------------------------------------------------------
>                 Key: HADOOP-6629
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6629
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: build
>            Reporter: Doug Cutting
>            Assignee: Doug Cutting
>         Attachments: HADOOP-6629.patch, HADOOP-6629.patch
> Currently the Maven POM file is generated from a template file that includes the versions
of all the libraries we depend on.  The versions of these libraries are also present in ivy/libraries.properties,
so that, when a library is updated, it must be updated in two places, which is error-prone.
 We should instead only specify library versions in a single place.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message