hadoop-common-issues mailing list archives

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

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

Paolo Castagna commented on HADOOP-6629:
----------------------------------------

There is another place where dependencies and version numbers are "duplicated", it's .eclipse.templates/.classpath
used to "generate" the Eclipse .classpath.

One possibility is to do:

{code}
  <target name="eclipse-files" depends="init"
          description="Generate files for Eclipse">
    <pathconvert property="eclipse.project">
      <path path="${basedir}"/>
      <regexpmapper from="^.*/([^/]+)$$" to="\1" handledirsep="yes"/>
    </pathconvert>
    <copy todir="." overwrite="true">
      <fileset dir=".eclipse.templates">
      	<exclude name="**/README.txt"/>
      </fileset>
      <filterset>
        <filter token="PROJECT" value="${eclipse.project}"/>
      </filterset>
      <filterset begintoken="{" endtoken="}">
      	<filtersfile file="${ivy.dir}/libraries.properties"/>
      </filterset>
    </copy>
  </target>
{code}

... and have in the .classpath template:

{code}
    [...]
	<classpathentry kind="lib" path="build/ivy/lib/Hadoop-Core/common/avro-{avro.version}.jar"/>
	<classpathentry kind="lib" path="build/ivy/lib/Hadoop-Core/common/commons-cli-{commons-cli.version}.jar"/>
	<classpathentry kind="lib" path="build/ivy/lib/Hadoop-Core/common/commons-codec-{commons-codec.version}.jar"/>
	<classpathentry kind="lib" path="build/ivy/lib/Hadoop-Core/common/commons-el-{commons-el.version}.jar"/>
    [...]
{code}

I had a few problems with JUnit, Jetty, JSP APIs and Slf4j dependencies.

It seems to me that the libraries.property file, as it is right now, is killing the benefit
of having a dependency engine such as Ivy to transitively resolve dependencies.

I had not time to replicate Avro's approach to generate Eclipse files, but IMHO it's better.

By the way, with Maven, once you have your pom.xml file, to generate Eclipse files you run:
mvn eclipse:eclipse -DdownloadSources=true. 

> 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.


Mime
View raw message