ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burt Leung <burt.le...@gmail.com>
Subject Redundant JAR files in configuration groups
Date Wed, 06 Jan 2010 00:18:01 GMT
Hi All,

This is sort of both a question and a suggestion.

The team that I am on is still in the process of (starting to) adopt Ivy as
part of our development process. One of the key concerns raised was the fact
that the use of configurations "groups" can produce redundant JAR files in
the lib folder.


For example, I currently have configurations defined for one of our modules
like so:
================
    <configurations>
        <conf name="compileSrcConf" description="Configuration for compiling
the source code."/>
        <conf name="default" extends="compileSrcConf" description="Default
configuration"/>

        <conf name="compileTestsConf" extends="compileSrcConf"
description="Configuration for compiling the test code."/>
        <conf name="checkstyleConf" extends="compileSrcConf"
description="Configuration for running checkstyle."/>
    </configurations>
   <dependencies>
       <dependency org="someDependencyA" name="collections" rev="1.0"
conf="compileSrcConf->default"/>
       <dependency org="someDependencyB" name="collections" rev="1.0"
conf="compileSrcConf->default"/>
       <dependency org="someDependencyC" name="collections" rev="1.0"
conf="compileSrcConf->default"/>
       <dependency org="someDependencyD" name="collections" rev="1.0"
conf="compileSrcConf->default"/>
       <dependency org="someDependencyE" name="collections" rev="1.0"
conf="compileSrcConf->default"/>
       <dependency org="someDependencyF" name="collections" rev="1.0"
conf="compileSrcConf->default"/>

       <dependency org="checkstyle" name="checkstyle" rev="4.1"
conf="checkstyleConf->default"/>

       <dependency org="junit" name="junit" rev="4.1"
conf="compileTestsConf->default"/>
   </dependencies>
================


Because some of the configurations extend the compileSrcConf configuration,
a typical Ivy retrieve will produce a lib folder that looks like the
following:
================
/lib/compileSrcConf/
                            someDependencyA.jar
                            someDependencyB.jar
                            someDependencyC.jar
                            someDependencyD.jar
                            someDependencyE.jar
                            someDependencyF.jar
/lib/compileTestsConf/
                            someDependencyA.jar
                            someDependencyB.jar
                            someDependencyC.jar
                            someDependencyD.jar
                            someDependencyE.jar
                            someDependencyF.jar
                            junit.jar
/lib/checkstyleConf/
                            someDependencyA.jar
                            someDependencyB.jar
                            someDependencyC.jar
                            someDependencyD.jar
                            someDependencyE.jar
                            someDependencyF.jar
                            checkstyle.jar
================


We are considering removing the "extends" attribute from each configuration
declaration so that there would not be this redundency of JAR files. We'd of
course have to setup composite paths/pathelements in the ANT build file so
that this would work. For example, an excerpt for the ANT build file:
================
    <property name="compileSrcLibDir"
value="${ivyResolveLibDir}/compileSrcConf"/>
    <property name="compileTestsLibDir"
value="${ivyResolveLibDir}/compileTestsConf"/>
    <property name="checkstyleLibDir"
value="${ivyResolveLibDir}/checkstyleConf"/>
    ...
    <!-- The classpath used to compile the module. -->
    <path id="classpath.module.compile">
        <fileset dir="${compileSrcLibDir}">
            <include name="**/*.jar" />
        </fileset>
    </path>

    <!-- The classpath used to compile the tests -->
    <path id="classpath.tests.compile">
        <fileset dir="${compileTestsLibDir}">
            <include name="**/*.jar" />
        </fileset>

        <path refid="classpath.module.compile" />    ***<== workaround for
not using "extends" feature in Ivy configuration.
    </path>


    <!-- The classpath used to compile the tests -->
    <path id="classpath.checkstyle">
        <fileset dir="${compileTestsLibDir}">
            <include name="**/*.jar" />
        </fileset>

       <path refid="classpath.module.compile" />   ***<== workaround for not
using "extends" feature in Ivy configuration.
    </path>
================


Question: is there a good argument for ignoring/tolerating this redundancy
of JAR files?

I personally think it would be nice if Ivy setup/provided ANT path elements
behind the scenes based on the Ivy configuration groups. As I understand it,
when Ivy does a resolve/retrieve, it first downloads the JAR files to its
cache directory on the computer (e.g. "c:/documents and
settings/user/.ivy/"). Then it will copy the JAR files specified by the
configuration group(s) defined in a module's ivy.xml into its lib folder
using a pattern like:

pattern="${ivyResolveLibDir}/[conf]/[organization]/[artifact]-[revision].[ext]"

Since the JAR files are already in the Ivy cache directory I think that Ivy
could (automatically) create ANT pathelements behind the scenes (for each
Ivy configuration group) that could then be referenced from the ANT build
file. This would save the "copy" step I mentioned above. Does anyone else
think this would be an improvement?

Thanks,
Burt

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message