ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Clitheroe <>
Subject Re: multiple ivy.xml files or configurations
Date Tue, 16 Jun 2009 21:19:47 GMT
Hi Barry,

configurations are definitely the way to go for what you are describing (I
found it very confusing for a while).

I've included an ivy file for a jar we publish.  For example the project

commons-httpclient for compilation and gets it in it's default
configuration conf="compile->default".  This will end up lib/compile.
The project also uses several runtime and test dependencies.  These go
into separate dirs beneath lib.  Also note that runtime extends
compile and test extends runtime
so anything that goes into lib/compile also goes into lib/runtime and lib/test.

Once we publish the project the ixy.xml goes with it and any project
that uses it as a dependency has to decide which configuration to use
it in.  For us this is typically default (say compile->default).

If you retroffiting ivy to projects and trying to understand the jar
maze then Tattle Tale is very helpful.


<?xml version="1.0" encoding="UTF-8"?>

<ivy-module version="2.0"

    <info organisation="" module="geonet-util"
revision="2.0.1" status="release" publication="20090526094640"/>


        <conf name="default" visibility="public" description="runtime
dependencies and master artifact can be used with this conf"

        <conf name="master" visibility="public" description="contains
only the artifact published by this module itself, with no transitive

        <conf name="compile" visibility="public" description="this is
the default scope, used if none is specified. Compile dependencies are
available in all classpaths."/>

        <conf name="provided" visibility="public" description="this is
much like compile, but indicates you expect the JDK or a container to
provide it. It is only available on the compilation classpath, and is
not transitive."/>

        <conf name="runtime" visibility="public" description="this
scope indicates that the dependency is not required for compilation,
but is for execution. It is in the runtime and test classpaths, but
not the compile classpath." extends="compile"/>

        <conf name="test" visibility="private" description="this scope
indicates that the dependency is not required for normal use of the
application, and is only available for the test compilation and
execution phases." extends="runtime"/>

        <conf name="system" visibility="public" description="this
scope is similar to provided except that you have to provide the JAR
which contains it explicitly. The artifact is always available and is
not looked up in a repository."/>

        <conf name="sources" visibility="public" description="this
configuration contains the source artifact of this module, if any."/>

        <conf name="javadoc" visibility="public" description="this
configuration contains the javadoc artifact of this module, if any."/>

        <conf name="foride" visibility="private" description="this
configuration contains the source and/or javadoc artifacts of this
modules dependecies for use to provide documentation in IDE."/>

        <conf name="optional" visibility="public"
description="contains all optional dependencies"/>


        <artifact name="geonet-util" type="jar" ext="jar" conf="master"/>
        <artifact name="geonet-util" type="source" ext="jar"
conf="sources" m:classifier="sources"/>
        <artifact name="geonet-util" type="doc" ext="jar"
conf="javadoc" m:classifier="javadoc"/>



        <dependency org="commons-httpclient" name="commons-httpclient"
rev="2.0.2" conf="compile->default"/>
<!-- these are runtime deps for commons-httpclient or commons-logging,
this _may_ not be the correct version,
there is no way to tell. -->
        <dependency org="javax.mail" name="mail" rev="1.4.2"
        <dependency org="javax.jms" name="jms" rev="1.1"
        <dependency org="com.sun.jmx" name="jmx" rev="1.1"
        <dependency org="com.sun.jmx" name="jmx-tools" rev="1.1"
        <dependency org="org.apache.avalon.logkit"
name="avalon-logkit" rev="2.2.1" conf="runtime->default"/>

        <dependency org="javax.servlet" name="servlet-api" rev="2.4"
<!-- end of manual deps for commons-* -->

        <dependency org="junit" name="junit" rev="4.1" conf="test->default"/>
        <dependency org="jdom" name="jdom" rev="0.7" conf="compile->default"/>
        <dependency org="joda-time" name="joda-time" rev="1.6"

        <dependency org="" name="gol-spatial"
rev="unknown-1" transitive="false" conf="compile->default"/>
<!-- gol-* deps, these are a tangled web... -->
        <dependency org="" name="gol-math"
rev="unknown-1" conf="runtime->default"/>
        <dependency org="" name="gol-core"
rev="unknown-1" conf="runtime->default"/>

        <dependency org="" name="gol-common"
rev="unknown-1" conf="runtime->default"/>
        <dependency org="" name="gol-db"
rev="unknown-1" conf="runtime->default"/>
        <!-- this has a lot of other deps of it's own but we have
never had them
             so I'm not going to go hunting for them. -->
        <dependency org="" name="arcims_jconnect"
rev="unknown-1" conf="runtime->default"/>
<!-- end of gol-* deps -->

        <dependency org="com.cenqua.clover" name="clover" rev="2.5.0"
revConstraint="latest." conf="optional->default"/>



On Wed, Jun 17, 2009 at 9:04 AM, Barry Pape <> wrote:

> Hello Ivy Community,
> I'm still learning Ivy, and am having some issues working with it.  Is
> it possible to have multiple ivy.xml files to be resolved?  For
> instance, if I have the following directory setup:
> lib/common
>    /main
>    /test
> Can I have a separate ivy.xml for each?  I can't seem to get ivy to use
> the non-default of ${basedir}/ivy.xml.  I've tried using both
> ivy.conf.file to point ivy to a file (ie. lib/common/ivy.xml or
> ${basedir}/ivy.common.xml) and ivy.conf.dir to point ivy to a subdir
> (ie. lib/common) and ivy doesn't seem to retain the override when
> performing ivy:retrieve.  I'm not seeing any attributes for ivy:retrieve
> that allow for the ivy.xml file to be configured.
> If that isn't possible, is using configurations the way to go?  I've
> tried this as well, but run into issues with the file I'm trying to
> retrieve not having the configuration.  I'm using an Artifactory
> repository that I created.  I've setup a couple of configurations in my
> ivy.xml and added the conf attribute to my dependency.  I also published
> a new jar with the configurations included in the ivy.xml that uploaded
> with it and updated the dependency with the new artifact version number.
> I still receive the configuration not found message.  Am I
> misunderstanding how to use configurations?
> Or am I on the wrong track and should take a different approach?
> Thanks,
> Barry
> Confidentiality Notice! This electronic transmission and any attached
> documents or other writings are confidential and are for the sole use of the
> intended recipient(s) identified above. This message may contain information
> that is privileged, confidential or otherwise protected from disclosure
> under applicable law. If the receiver of this information is not the
> intended recipient, or the employee, or agent responsible for delivering the
> information to the intended recipient, you are hereby notified that any use,
> reading, dissemination, distribution, copying or storage of this information
> is strictly prohibited. If you have received this information in error,
> please notify the sender by return email and delete the electronic
> transmission, including all attachments from your system.

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