Overview

Ivy is a free java based dependency manager, with powerful features such as transitive dependencies, ant integration, maven repository compatibility, continuous integration, html reports and many more.

After several months of development, users feedback and testing, Ivy 1.0 is available !

Apart its strong dependency management engine, Ivy also benefits from a growing user community, a public repository of common ivy files, an evolving set of surrounding tools and plugins, and professional quality services directly from the authors.

Main features

simple to use
extremely flexible
easily extensible
high performances
integrated with ant
ready to use with maven ibiblio repository
transitive dependencies
eases continuous integration
publishing handling
clean dependency reports
heavily tested
strong conflict management
professional support
make your software component a lot simpler to use
free (BSD license) !

Testimonials

"Now that Ivy 1.0 is out, I’d strongly encourage every Java developer to pull it down and consider using it to manage dependencies in their Ant builds. As far as I’m concerned, it’s a complete no-brainer." Read more

Colin Sampaleanu, core developer of Spring

"Ivy's a great library... I've just gone through and implemented a multi-module build using Ivy for full transitive dependency management..." Read more

Jason Careira, webwork and xwork project leader

"Currently, our application uses more than 40 3rdparty jars. [...] With Ivy, I now have a full accounting of what libraries our project relies on directly. [...] We now have clear understanding of our dependency tree" Read more

Scott Haug, core developer of jobster.com

Tools and plugins

Great tools and plugins help you leverage the power of Ivy:

Ivy CruiseControl Plugin let you integrate ivy in the famous continuous integration tool from thoughtworks: cruisecontrol.

Ivy Eclipse UI strongly help eclipse users to write their ivy files, with structural and data completion.

Coming soon:
Subversion Dependency Resolver, let you use subversion to store your libraries
Ivy Eclipse Classpath, let you use ivy files as a library container

Main benefits

Simplicity

For simple cases, ivy is really simple to use. Declare your dependencies, and that's all. See the very simple example below to check yourself.
Ivy can thus be used to bring the dependency management feature of maven to ant build file, for those of you who already use ant and who do not want to setup a maven project. But Ivy does not stop here, as you can see in the following main benefits...

Transitive dependencies management

Imagine you have a component that you often reuse in your software developments. Imagine that this component has itself dependencies. Then with classical dependencies management, each time you use this component in your software you have to declare it as a dependency, but also all its dependencies.

With ivy it's different: you simply write a dependency file once for the component, declaring its own dependencies, then anytime you want to use this component you simply have to declare a dependency on it.

And this is even more powerful if the component your software depends on changes of dependencies during its own development. Then, without ivy, you have to maintain all your components dependencies declaration each time the dependencies of this component change. With ivy, you update the ivy file of the component and that's it ! Note: if you want to quickly start using this feature or simply see it in action with real world examples, check the official repository: ivyrep

Continuous integration ready

Are you working in a continuous integration environment ? No ? You should ;-)

If you are working in a continuous integration environment, and if you have many projects that depend one on each other, then you are maybe experiencing the dependency management nightmare... Fortunately, ivy is there to help !

With ivy you can declare that a component depends on the latest version of another component. Knowing that, ivy will search for the latest version of the dependency whenever you ask it to do so. This latest version is computed by ivy simply either by checking the date of the dependency versions or by comparing versions as text (either lexicographically or with an algorithm close to the one used in php version_compare function). You have nothing special to do to benefit from this feature: install ivy, configure it, write your dependency files, and that's it !

Simple example

The simplest way to use ivy is to call it from your ant build file. Here's the 3 steps easiest way to first use it, assuming you already have ant installed:

1. Download and install

Download the latest version here, unpack the downloaded zip file wherever you want, and copy the ivy jar file in your ant lib directory (ANT_HOME/lib).

2. Describe your dependencies

To describe your dependencies, you just have to create a file named ivy.xml in your project base directory (as known by ant).
Write your dependencies description in this file, as here :

<ivy-module version="1.0">
    <info organisation="mycompany" module="mycomponent"/>
    <dependencies>
        <dependency name="commons-lang" rev="2.0"/>
        <dependency name="log4j" rev="1.2.8"/>
    </dependencies>
</ivy-module>

The version given at the beginning of the file is the ivy file specification version, it should thus always be 1.0 with current ivy version.
In the info tag you describe the component for which you are describing dependencies.
Then you just have to list the dependencies your component has. In order to work with as little configuration as possible, the name of the dependencies should be the name of the directory under maven ibiblio repository, and the revision should be the one found in the jars directory in this same repository.

3. Call ivy from your ant build file

If you use ant 1.6.0 or superior version, this is really simple. You just have to add this attribute to your project tag :

xmlns:ivy="antlib:fr.jayasoft.ivy.ant"

Then call ivy retrieve task in the target you like. Example:

<target name="resolve">
  <ivy:retrieve/>
</target>

You now can call this target with ant. You should then see that ivy created a lib directory in your project, containing the dependencies jar downloaded from ibiblio ! That's it, you can now use them to build a classpath or anything you want... and you are still far far away from ivy possibilities. Check the tutorial to discover some of them, and do not forget to read the reference documentation to go even further in your knowledge of the power of ivy !

About this site

This site allows you to comment each page to share your experience about any feature or documentation. You have to be registered to post a comment, it's simple, quick, free, and you will not be spammed with e-mails, don't worry. You can also use the forum to ask questions ( registration required).
You can find documentation either on this site and in the distribution. But prefer the site, it is always more up to date and you can post and view comments on each page.
A single page documentation is also available.

Hello ivy

top

Starting with ivy

In this example, we will see the easiest way to use ivy. No configuration or other complicated files to write, only the list of libraries the project will use.

The ivy.xml file

This file is used to describe, the dependencies of the project on other libraries. Here is the sample :

<ivy-module version="1.0">
    <info organisation="jayasoft" module="hello-ivy" />
    <dependencies>
        <dependency name="commons-lang" rev="2.0" />
    </dependencies>
</ivy-module>

The build file corresponding to use it, contains only :

<project xmlns:ivy="antlib:fr.jayasoft.ivy.ant" name="hello-ivy" default="run">

    ...

    
    <target name="resolve" description="--> retreive dependencies with ivy">
        <ivy:retrieve />
    </target>
</project>

Running the project

To run the sample, open a dos (or shell) window, and go under the hello-ivy example directory. Then, on the command prompt, just run ant :

I:\hello-ivy>ant
Buildfile: build.xml

resolve:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::
no configuration file found, using default...
:: resolving dependencies :: jayasoft/hello-ivy-working@xmen
        confs: [default]
downloading http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar(2.0) ...
..................................... (165kB)
        [SUCCESSFUL ] apache/commons-lang-2.0/commons-lang.jar[jar] (4688ms)
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   1   |   1   |   0   |   0   ||   1   |   1   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/hello-ivy
        confs: [default]
        1 artifacts copied, 0 already retrieved

run:
    [mkdir] Created dir: I:\hello-ivy\build
    [javac] Compiling 1 source file to I:\hello-ivy\build
     [java] standard message : hello ivy !
     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !

BUILD SUCCESSFUL
Total time: 8 seconds

What happened ?

Without any configuration, other than it's default configuration, ivy retreive files from the maven ibiblio libraries repository. That's what happened here. The resolve task has downloaded the commons-lang.jar file from ibiblio, then copied it to the ivy cache and then dispatch it in the default library directory of the project : the lib dir.
Some will say that the task was long to achieve. Yeah, it's true it was, but it has downloaded from the internet the needed file. Let's try to run it again :

I:\hello-ivy>ant
Buildfile: build.xml

resolve:
:: resolving dependencies :: jayasoft/hello-ivy-null :: [default]
:: resolution report ::
        [default] jayasoft/hello-ivy-working@rahan: 1 artifacts (0 downloaded)
:: retrieving :: jayasoft/hello-ivy :: [default]

run:
     [java] standard message : hello ivy !
     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !

BUILD SUCCESSFUL
Total time: 1 second

Great ! the cache was used, no download was needed and the build was instantaneous.

If you want to check the content of the cache, by default it is put in your user home in a .ivy-cache directory.

And now, if you want to generate a report detailing all the dependencies of your module, you can call the report target, and check the generated file in the build directory. You should obtain something looking like this.

You are now ready to go to the next tutorials to go one step beyond using ivy transitive dependencies management.

Using IvyRep

top

Starting with ivy

In this example, we will see the easiest way to use ivy and benefit from its transitive dependencies feature. No configuration or other complicated files to write, only the list of libraries the project will use.

The ivy.xml file

This file is used to describe, the dependencies of the project on other libraries. Here is the sample :

<ivy-module version="1.0">
    <info organisation="jayasoft" module="hello-ivy" />
    <dependencies>
        <dependency org="apache" name="commons-lang" rev="2.0" />
        <dependency org="apache" name="commons-cli" rev="1.0" />
    </dependencies>
</ivy-module>

The build file corresponding to use it, contains only :

Running the project

To run the sample, open a shell window, and go under the ivyrep example directory. Then, on the command prompt, just run ant :

I:\ivyrep>ant
Buildfile: build.xml

resolve:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::
no configuration file found, using default...
:: resolving dependencies :: jayasoft/ivyrep-example-working@xmen
        confs: [default]
downloading http://www.ibiblio.org/maven/commons-cli/jars/commons-cli-1.0.jar(1.0) ...
...... (31kB)
        [SUCCESSFUL ] apache/commons-cli-1.0/commons-cli.jar[jar] (1437ms)
downloading http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar(2.0) ...
..................................... (165kB)
        [SUCCESSFUL ] apache/commons-lang-2.0/commons-lang.jar[jar] (5640ms)
downloading http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.jar(1.0) ...
..... (21kB)
        [SUCCESSFUL ] apache/commons-logging-1.0/commons-logging.jar[jar] (1250ms)
:: resolution report ::
        :: evicted modules:
        apache/commons-lang-1.0 by [apache/commons-lang-2.0] in [default]
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   4   |   3   |   2   |   1   ||   3   |   3   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/ivyrep-example
        confs: [default]
        3 artifacts copied, 0 already retrieved

run:
    [mkdir] Created dir: I:\ivyrep\build
    [javac] Compiling 1 source file to I:\ivyrep\build
     [java] standard message : hello ivy !
     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !

BUILD SUCCESSFUL
Total time: 16 seconds

What happened ?

Without any configuration, other than it's default configuration, ivy uses the ivyrep resolver. This resolver looks for ivy files on ivyrep, and for artifacts on ibiblio. That's what happened here.

The resolve task has found an ivy file on ivyrep for commons-cli 1.0. This ivy file indicates that commons-cli 1.0 depends on commons-lang 1.0 and commons-logging 1.0.

The resolve task detects the conflict between the revision 2.0 of commons-lang that is asked in the ivy above, and the revision 1.0 required in commons-cli. With no particular conflict manager, the 2.0 is selected, and the 1.0 is evicted. The 1.0 being evicted, it is not downloaded at all.

The resolve task has then downloaded the commons-cli 1.0, commons-logging 1.0 and commons-lang.jar 2.0 files from ibiblioand put them to the ivy cache.
Then the retrieve task has copied them in the default library directory of the project : the lib dir.
Some will say that the task was long to achieve. Yes, it's true it was, but it has downloaded from the internet the needed files. Let's try to run it again :

I:\ivyrep>ant
Buildfile: build.xml

resolve:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::
no configuration file found, using default...
:: resolving dependencies :: jayasoft/ivyrep-example-working@xmen
        confs: [default]
:: resolution report ::
        :: evicted modules:
        apache/commons-lang-1.0 by [apache/commons-lang-2.0] in [default]
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   4   |   0   |   0   |   1   ||   3   |   0   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/ivyrep-example
        confs: [default]
        0 artifacts copied, 3 already retrieved

run:
     [java] standard message : hello ivy !
     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !

BUILD SUCCESSFUL
Total time: 2 seconds

Great ! the cache was used, no download was needed and the build was almost instantaneous.

If you want to check the content of the cache, by default it is put in your user home in a .ivy-cache directory. Check the next tutorials to see how to configure this.

Multiple resolvers

top

purpose

This example is an illustration of how artefacts can be retreived by multiple resolvers. Using multiple resolvers is very important when using continous integration. Indeed, in such environements, you can use multiple repositories and so multiple resolvers to retreive both released versions of projects than continous integrated versions produced for example with cruise-control. In our example, we will just show how to use two resolvers, one on a local repository and one using ibiblio repository.

project description

the project : chained-resolvers

The project is very simple and contains only one test class : example.Hello
It depends on two libraries apache commons-lang and a little test library (sources are included in jar file). The test library is used by the project to uppercase a string, and commons-lang is used to capitalize the same string. Here is the content of the project :

build.xml : the ant build file for the project
ivy.xml : the ivy project file
src\example\Hello.java : the only class of the project

Take a look at it's ivy.xml file :

<ivy-module version="1.0">
    <info organisation="jayasoft" module="chained-resolvers" />
    <dependencies>
        <dependency org="apache" name="commons-lang" rev="2.0" />
        <dependency name="test" rev="1.0" />
    </dependencies>
</ivy-module>

As we expect, the ivy file declares to be dependent on the two libraries that the project use : apache commons-lang.jar and test.jar.

the ivy configuration

The ivy configuration is made in the config directory it contains only one file : ivyconf.xml. Let's analyse it.

the conf tag

This tag initializes ivy with some parameters. Here only one is used, the name of the resolver to use by default.

the resolvers tag

Under this tag, we can find the description of the resolvers that ivy will use. In our example, we have only one resolver, called "chain-example", which is quite special as it defines a list (a chain) of resolvers. The resolvers put in the chain are :

libraries : it is a file resolver. This one is configured to look for artefacts in the "repository" sub directory of the directory that contains the ivyconf.xml file.
ibiblio : this resolver is a special one. It looks in the ibiblio maven repository to retreive the libraries. More information on it here.

walkthrough

step 1 : preparation

Open a DOS or shell window, and go to the "chained-resolvers" directory.

step 2 : clean directory tree

On the prompt type : ant
This will clean up the entire project directory tree and ivy cache. You can do it each time you want to clean up this example.

step 3 : run the project

Goto chainedresolvers-project directory. And simply run ant.

I:\chained-resolvers\chainedresolvers-project>ant
Buildfile: build.xml

configure:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::

resolve:
:: resolving dependencies :: jayasoft/chained-resolvers-working@xmen
        confs: [default]
downloading http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar(2.0) ...
.................................... (165kB)
        [SUCCESSFUL ] apache/commons-lang-2.0/commons-lang.jar[jar] (5390ms)
downloading file:/I:/chained-resolvers/config/repository/test-1.0.jar(1.0) ...
. (1kB)
        [SUCCESSFUL ] jayasoft/test-1.0/test.jar[jar] (16ms)
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   2   |   2   |   0   |   0   ||   2   |   2   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/chained-resolvers
        confs: [default]
        2 artifacts copied, 0 already retrieved

run:
    [mkdir] Created dir: I:\chained-resolvers\chainedresolvers-project\build
    [javac] Compiling 1 source file to I:\chained-resolvers\chainedresolvers-project\build
     [java] standard message :example world !
     [java] capitalized by org.apache.commons.lang.WordUtils : Example World !
     [java] upperCased by test.StringUtils : EXAMPLE WORLD !

BUILD SUCCESSFUL
Total time: 9 seconds

We can see in the log of the resolve task, that the two dependencies have been retrieved (2 artifacts) and copied to the ivy cache directory (2 downloaded). The run target succeed in using both commons-lang.jar comming from ibiblio repository and test.jar comming from the local repository.

Dual resolver

top

Dual Resolver Tutorial

This tutorial presents the use of the DualResolver, a feature introduced in the version 0.6 of Ivy.

Dual Resolver is used when ivy files can be found in a repository while artifacts are in another. It is especially useful to use full power of ivy (including transitive dependencies) with the ibiblio repository for artifacts. The problem with the maven ibiblio repository is that it does not contain ivy files. Since transitive dependencies are based upon ivy files, using the ibiblio resolver does not permit to use transitive dependencies.

The solution to this problem is to store your own repository only for ivy files, and use ibiblio for artifacts. That's what is done in this tutorial.

project description

Let's have a look at the src/example/dual directory in your ivy distribution.
It contains a build file and 3 directories:

config: contains the ivy configuration file
repository: a sample repository of ivy files
project: the project making use of ivy with dual resolver

the dual project

The project is very simple and contains only one test class : example.Hello
It depends on two libraries: apache commons-lang and apache commons-httpclient. Here is the content of the project :

build.xml : the ant build file for the project
ivy.xml : the ivy project file
src\example\Hello.java : the only class of the project

Take a look at it's ivy.xml file :

<ivy-module version="1.0">
    <info organisation="jayasoft" module="hello-ivy" />
    <dependencies>
        <dependency org="apache" name="commons-httpclient" rev="2.0.2" />
        <dependency org="apache" name="commons-lang" rev="2.0" />
    </dependencies>
</ivy-module>

As you can see, nothing special here... Indeed, it's the philosophy of ivy to keep ivy files independent of the way dependencies are retrieved.

the ivy configuration

The ivy configuration is made in the config directory it contains only one file : ivyconf.xml. Let's analyse it.

Here we configure one resolver, the default one, which is a dual resolver. This dual resolver has two sub resolvers : the first is what is called the "ivy" resolver of the dual resolver, and the second one is what is called the "artifact" resolver. It is important that the dual resolver exactly has two sub resolvers in this given order.
The ivy resolver, here a filesystem one, is used only to find ivy files. The configuration given in this resolver says that all ivy files are in the same directory, named like that: [module]-ivy-[revision].xml. If we check the repository directory, we can confirm that it contains a file named commons-httpclient-ivy-2.0.2.xml. It fulfills the given pattern and will thus be find by this resolver.
The artifact resolver is simply an ibiblio one, and will thus try to find required artifacts in the maven ibiblio repository.

walkthrough

step 1 : preparation

Open a DOS or shell window, and go to the "dual" directory.

step 2 : clean up

On the prompt type : ant
This will clean up the entire project directory tree (compiled classes and retrieved libs) and ivy cache. You can do it each time you want to clean up this example.

step 3 : run the project

Goto project directory. And simply run ant.

I:\dual\project>ant
Buildfile: build.xml

configure:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::

resolve:
:: resolving dependencies :: jayasoft/hello-ivy-working@xmen
        confs: [default]
downloading http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar(2.0) ...
.....
.........
..........
...........
. (165kB)
        [SUCCESSFUL ] apache/commons-lang-2.0/commons-lang.jar[jar] (8032ms)
downloading http://www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.2.jar(2.0.2) ...
...........
......
....
..........
............
........ (220kB)
        [SUCCESSFUL ] apache/commons-httpclient-2.0.2/commons-httpclient.jar[jar] (10031ms)
downloading http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.4.jar(1.0.4) ...
......... (37kB)
        [SUCCESSFUL ] apache/commons-logging-1.0.4/commons-logging.jar[jar] (1469ms)
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   3   |   3   |   1   |   0   ||   3   |   3   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/hello-ivy
        confs: [default]
        3 artifacts copied, 0 already retrieved

run:
    [mkdir] Created dir: I:\dual\project\build
    [javac] Compiling 1 source file to I:\dual\project\build
     [java] standard message : hello ivy !
     [java] capitalized by org.apache.commons.lang.WordUtils : Hello Ivy !
     [java] head status code with httpclient: 200
     [java] now check if httpclient dependency on commons-logging has been realized
     [java] found logging class in classpath: interface org.apache.commons.logging.Log

BUILD SUCCESSFUL
Total time: 24 seconds

As you can see, ivy not only downloaded commons-lang and commons-httpclient, but also commons-logging. Indeed, commons-logging is a dependency of httpclient, as we can see in the httpclient ivy file found in the repository directory:

<ivy-module version="1.0">
    <info organisation="apache" module="commons-httpclient" revision="2.0.2" status="release" publication="20041010174300" />
    <dependencies>
        <dependency name="commons-logging" rev="1.0.4" conf="default" />
    </dependencies>
</ivy-module>

So everything worked well, ivy file has been found in the repository directory and artifacts have been downloaded from ibiblio. You now just have to write ivy files for the module you often use, and they will be much easier to use... And imagine a world in which each module delivers also an ivy file. Since it is independent of the way to retrieve dependencies, it would made all dependencies handling much easier, wouldn't it ?

Projects dependency

top

purpose

This example is an illustration of dependency between two project. The dependant project declares that it uses the standalone one. We will illustrate two things :

public libraries declared by standalone project will automatically be recovered by the dependant project
the dependant project will retrieve the "latest" version of the standalone project

the projects used

the project : standalone

The standalone project is very simple. It depends on the apache library commons-lang and contains only one class : standalone.Main which provides two services :

return the version of the project
capitalize a string using org.apache.commons.lang.WordUtils.capitalizeFully

Here is the content of the project :

build.xml : the ant build file for the project
ivy.xml : the ivy project file
src\standalone\Main.java : the only class of the project

Take a look at it's ivy.xml file :

<ivy-module version="1.0">
    <info organisation="jayasoft" module="standalone" />
    <dependencies>
        <dependency org="apache" name="commons-lang" rev="2.0" />
    </dependencies>
</ivy-module>

The ivy dependency file declares only one dependency on apache commons-lang library which by default is a public dependency (see ivy file definition).

the project : depending

The project depending is very simple too. It declares only one dependency on the latest version of the standalone project and it contains only one class depending.Main which make 2 things :

getting the version of the standalone project throw a call to standalone.Main.getVersion()
transform a string throw a call to standalone.Main.capitalizeWords(str)

Take a look at it's ivy.xml file :

<ivy-module version="1.0">
    <info organisation="jayasoft" module="depending" />
    <dependencies>
        <dependency name="standalone" rev="latest.integration" />
    </dependencies>
</ivy-module>

the ivy configuration

The ivy configuration is made in the config directory wich contains 2 files :

ivyconf.properties : a property file
ivyconf.xml : the file containing the ivy configuration

Let's analyse the ivyconf.xml file.

The file contains four main tags : properties, conf, resolvers and modules.

the properties tag

This tag only load some properties for the ivy process in the same manner as ant will do it.

the conf tag

This tag is in charge to initialize some parameters for ivy process. The directory that ivy will use to cache (to store) artifacts found will be in a sub directory called ivy-cache of the directory containing the ivyconf.xml file itself. The second parameter, tells ivy to use a resolver called "libraries" as its default resolver. As a recall, a resolver is in charge to resolve an artifact from some information like : the organisation that provides the artifact, the name of the library and the version of the library. More information can be found in the configuration documentation.

the resolvers tag

This tag defines the resolvers to use. Here we have two resolvers defined: "projects" and "libraries".
The filesystem resolver called "projects" is able to resolve the internal dependencies wanted.
The ivyrep resolver called "libraries" is able to find dependencies on ivyrep.

the modules tag

The modules tag allows to configure which resolver should be use for which module. Here the configuration only tells to use the "projects" resolver for all modules having for organisation "jayasoft" and any module name (.* regexp matches any module name).
For other modules (i.e. all modules not from jayasoft), since there is no special configuration, the default resolver will be used: "libraries".

walkthrough

step 1 : preparation

Open a DOS or shell window, and go to the "dependance" directory.

step 2 : clean directory tree

On the prompt type : ant
This will clean up the entire project directory tree. You can do it each time you want to clean up this example.

step 3 : publication of standalone project

Goto standalone directory and publish the project

I:\standalone>ant publish
Buildfile: build.xml

configure:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::

resolve:
:: resolving dependencies :: jayasoft/standalone-working@xmen
        confs: [default]
downloading http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar(2.0) ...
.................................... (165kB)
        [SUCCESSFUL ] apache/commons-lang-2.0/commons-lang.jar[jar] (6672ms)
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   1   |   1   |   0   |   0   ||   1   |   1   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/standalone
        confs: [default]
        1 artifacts copied, 0 already retrieved

compile:
    [mkdir] Created dir: I:\standalone\build\classes
    [javac] Compiling 1 source file to I:\standalone\build\classes

jar:
[propertyfile] Creating new property file: I:\standalone\build\classes\version.properties
      [jar] Building jar: I:\standalone\build\standalone.jar

publish:
:: delivering :: jayasoft/standalone-working@xmen :: 1 :: release :: Wed Apr 27 08:41:47 CEST 2005
        delivering ivy file to I:\standalone/build/ivy.xml
:: publishing :: jayasoft/standalone-working@xmen
        published standalone to I:\config\repository\standalone-1.jar
        published ivy to I:\config\repository\standalone-1.xml
     [echo] project standalone released with version 1

BUILD SUCCESSFUL
Total time: 10 seconds

What we see here :

the project depends on 1 library (1 artifact)

the library was not in the ivy cahe and so was downloaded (1 downloaded)

the project has been released under version number 1

To give more details on the publish, as you can see the call to the publish task has resulted in two main things:
- the delivery of a resolved ivy file to build/ivy.xml. This has been done because by default the publish task not only publishes artifacts but also ivy file. So it has looked to the path where the ivy file to publish should be, using the artifactspattern: ${build.dir}/[artifact].[ext]. For an ivy file, this resolves to build/ivy.xml. Because this file does not exist, it automatically make a call to the deliver task which delivers a resolved ivy file to this destination.
- the publication of artifact standalone and resolved ivy file to the repository. Both are mere copy of files found in the current project, more precisely in the build dir. This is because the artifactspattern has been set to ${build.dir}/[artifact].[ext], so standalone artifact is found in build/standalone.jar and ivy file in build/ivy.xml. And because we have asked the publish task to publish them using the "projects" resolver, these files are copied to repository\standalone-1.jar and to repository\standalone-1.xml, respecting the artifact and ivy patterns of our configuration (see above).

step 4 : running the depending project

Goto to directory depending and run ant

I:\depending>ant
Buildfile: build.xml

clean:

configure:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::

resolve:
:: resolving dependencies :: jayasoft/depending-working@xmen
        confs: [default]
        [1] jayasoft/standalone
downloading file:/I:/config/repository/standalone-1.jar(1) ...
. (1kB)
        [SUCCESSFUL ] jayasoft/standalone-1/standalone.jar[jar] (15ms)
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   2   |   2   |   2   |   0   ||   2   |   1   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/depending
        confs: [default]
        2 artifacts copied, 0 already retrieved

compile:
    [mkdir] Created dir: I:\depending\build\classes
    [javac] Compiling 1 source file to I:\depending\build\classes

run:
     [java] you are using version 1 of class standalone.Main
     [java] standard message : i am depending.Main and standalone.Main will do the job for me
     [java]     [standalone.Main] capitalizing string "i am depending.Main and standalone.Main will do the job for me" 
				     using org.apache.commons.lang.WordUtils
     [java] capitalized message : I Am Depending.main And Standalone.main Will Do The Job For Me

BUILD SUCCESSFUL
Total time: 3 seconds

What we see here :

the project depends on 2 libraries (2 artifacts)
one of the libraries was in the cache because there was only 1 download (1 downloaded)
ivy retreived the version 1 of the project standalone. The call to standalone.Main.getVersion() has returned 1. If you look in the depending/lib directory, you should see standalone-1.jar which is the artifact version 1 of the project standalone
the call to standalone.Main.capitalizeWords(str) succeed, what significate that the required library were in the classpath. If you look at the lib directory, you will see that the library commons-lang-2.0.jar was retreived. This library was declared to be used by the project "standalone", so ivy get it too for the dependant project.

step 5 : new version of standalone project

Like we did before in step 3, publish again the standalone project. This will result as a new version of the project.

I:\standalone>ant publish
Buildfile: build.xml

configure:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::

resolve:
:: resolving dependencies :: jayasoft/standalone-working@xmen
        confs: [default]
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   1   |   0   |   0   |   0   ||   1   |   0   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/standalone
        confs: [default]
        0 artifacts copied, 1 already retrieved

compile:

jar:
[propertyfile] Updating property file: I:\standalone\build\classes\version.properties
      [jar] Building jar: I:\standalone\build\standalone.jar

publish:
   [delete] Deleting: I:\standalone\build\ivy.xml
:: delivering :: jayasoft/standalone-working@xmen :: 2 :: release :: Wed Apr 27 09:17:13 CEST 2005
        delivering ivy file to I:\standalone/build/ivy.xml
:: publishing :: jayasoft/standalone-working@xmen
        published standalone to I:\config\repository\standalone-2.jar
        published ivy to I:\config\repository\standalone-2.xml
     [echo] project standalone released with version 2

BUILD SUCCESSFUL
Total time: 2 seconds

Now if you look in your repository folder, you must find 2 version published of the standalone project.
Let's look at it :

I:\dependence\standalone>dir ..\config\repository /w
 Le volume dans le lecteur I s'appelle DATA
 Le numéro de série du volume est 30E5-91BA

 Répertoire de I:\dependence\config\repository

[.]                [..]               standalone-1.jar   standalone-1.xml   standalone-2.jar   standalone-2.xml
               4 fichier(s)            3 936 octets
               2 Rép(s)   9 874 350 080 octets libres

I:\dependence\standalone>

Ok now our repository contains two versions of the project standalone, other projects can refer to both versions.

step 6 : depending got the new version

What do we expect about running again the depending project ? Two major things are expected :

retrieve the version 2 as the latest.integration version of the standalone project
running the test must display version 2 of standalone project

Let's go !!!

I:\depending>ant
Buildfile: build.xml

clean:
   [delete] Deleting 3 files from I:\depending
   [delete] Deleted 4 directories from I:\depending

configure:
:: Ivy 1.0-rc3 - 20050421161206 :: http://ivy.jayasoft.org/ ::

resolve:
:: resolving dependencies :: jayasoft/depending-working@xmen
        confs: [default]
        [2] jayasoft/standalone
downloading file:/I:/config/repository/standalone-2.jar(2) ...
. (1kB)
        [SUCCESSFUL ] jayasoft/standalone-2/standalone.jar[jar] (0ms)
:: resolution report ::
        ---------------------------------------------------------------------
        |                  |            modules            ||   artifacts   |
        |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
        ---------------------------------------------------------------------
        |      default     |   2   |   2   |   2   |   0   ||   2   |   1   |
        ---------------------------------------------------------------------
:: retrieving :: jayasoft/depending
        confs: [default]
        2 artifacts copied, 0 already retrieved

compile:
    [mkdir] Created dir: I:\depending\build\classes
    [javac] Compiling 1 source file to I:\depending\build\classes

run:
     [java] you are using version 2 of class standalone.Main
     [java] standard message : i am depending.Main and standalone.Main will do the job for me
     [java]     [standalone.Main] capitalizing string "i am depending.Main and standalone.Main will do the job for me" 
			     using org.apache.commons.lang.WordUtils
     [java] capitalized message : I Am Depending.main And Standalone.main Will Do The Job For Me

BUILD SUCCESSFUL
Total time: 3 seconds

Ok we have the result expected as the run target shows that we are using the version 2 of the main class of standalone project. If we take a look at the resolve target results, we can see that one artifact has been downloaded to the ivy cache. In fact this file is the version 2 of the standalone project that was taken from the repository, you can now retrieve it in the ivy-cache directory.

Reference

top

Presentation

Here is the reference documentation of Ivy, a simple but powerful dependency manager. In this documentation, you will learn how to:

In fact, ivy distinguishes two different steps for describing and get your dependencies:
You write ivy files to describe the dependencies of your module, independently of how you retrieve them. Then you configure ivy to indicate it where it can find your dependencies. Thus you can easily share your ivy files, even if you have internal dependencies which are not resolved the same way in your environment as in the target development environment. You just have to have two configurations with the same ivy files. This is really nice when your ivy files are the reference of your module dependencies, which will be soon the case if you like it !

But before learning all of this, it is necessary to learn some vocabulary...

Terminology

Here are some terms used in Ivy, with their definitions in Ivy:

Organisation

An organisation is either a company or a simple group of person which produce software. Ivy handle only one level of organisation, so you cannot describe a company hierarchy with this concept. But it is used to group sofware produced by a same team, just to help find and classify them.
Examples: apache, ibm, jayasoft

Module

A module in ivy is a piece of software that is reusable, and that follow a unique cycle of revision.
Examples: hibernate, ant, ...

Artifact

An artifact is a single file produced by a company when releasing a module. In the java world, common artifacts are jars. In many cases, each revision of a module publish only one artifact (like log4j, for instance), but some of them publish many artifacts dependending on the use of the module (like ant, for instance).

Revision

A revision corresponds to one delivery of a module. It can either be a delivery of a release, a milestone, a beta version, a nightly build, or even a continuous build. All of them are considered revisions in ivy.

Configuration

A module configuration is a way to use or construct a module. Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server). Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those differents ways to use or build a module are called in ivy configurations.

Status

A module status indicates how stable a module revision can be considered. It can be used to consolidate the status of all the dependencies of a module, to prevent the use of an integration revision of a dependency in the release of your module. Currently, three status are used in ivy:

integration: revisions builded by a continuous build, a nightly build, and so on, fall in this category
milestone: revisions delivered to the public but not actually finished fall in this category
release: revision fully tested and labelled fall in this category

Main concepts

Dependency Resolver

A dependency resolver is a pluggable class in ivy which is used to:

find dependencies ivy files
download dependencies artifacts

The notion of artifact "downloading" is large: artifact can be on a web site, or on the local file system of your machine. The download is thus the fact to bring a file from a repository to ivy cache.

Moreover, the fact that it is the responsibility of the resolver to find ivy files and download artifacts help to implement various resolving strategies.

As you see, a dependency resolver can be thought as a class responsible of describing a repository.

Latest Strategy

Ivy often needs to know which revision between two has to be considered the "latest". For knowing that, it uses the concept of latest strategy. Indeed, there are several way to consider a revision to be the latest. You can choose an existing one or plug your own.

Ivy has three built-in latest strategies:
- latest-time: it compares the revisions date to know which is the latest. While this is often a good strategy in terms of pertinence, it has the drawback to be costful to compute with distant repositories. If you use ivyrep, for example, ivy has to ask the http server what is the date of each ivy file before knowing which is the latest.
- latest-revision: it compares the revisions as string, using an algorithm close to the one used in the php version_compare function. This algorithm takes into account special meaning of some text. For instance, with this strategy, 1.0-dev1 is considered before 1.0-alpha1, which in turn is before 1.0-rc1, which is before 1.0, which is before 1.0.1.
- latest-lexico: it compares the revisions as string, using lexicographic order (the one used by java string comparison).

Conflict Manager

A conflict manager is able to select, among a list of module revisions in conflict, a list of revisions to keep. Yes, it can selects a list of revision, even if most conflicts manager select only one revision. But in some cases you will need to keep several revisions, and load in separate class loaders, for example.

A list of revisions is said to be in conflict if they correspond to the same module, i.e. the same organisation/module name couple.

Ivy comes with 4 built-in conflicts manager, but you can also plug your own:
- all: this conflicts manager resolve conflicts by selecting all revisions. Also called NoConflictManager, it does evict any module.
- fixed: this conflict manager always select the same revision
- latest-time: this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
- latest-revision: this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions as defined by the latest-revision strategy.

To have more details on how to setup your conflict managers and on how they work, see ivy file reference.

Variables

During configuration, ivy allows to define what are called ivy variables. Ivy variables can be seen as ant properties, and are used in a very similar way. In particular, you use a properties tag in the configuration file to load a properties file containing ivy variables and their values.

But the main differences between ant properties and ivy variables are that ivy variables can be overriden, whereas ant properties can't, and that they are defined in separate environment.

In fact all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant). This means that if you define an ant property after the call to configure, it will not be available as an ivy variable.
On the other hand, ivy variables are NOT exported to ant, thus if you define ivy variables in ivy, do not try to use them as ant properties.

To use ivy variables, you just have to follow that same syntax as for ant properties:
${variablename}
where variablename is the name of the variable.

Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens. See Patterns chapter below to see what pattern tokens are.

Here is a table summing up the default variables availables in ivy:

Name	Set by	default value / description
ivy.conf.dir	configure	Points to the directory in which the configure file can be found
ivy.conf.url	configure	Points to the configuration url given for configuration
ivy.conf.file	configure(File)	Points to the configuration file given for configuration
ivy.project.dir	configure task	${basedir}
ivy.project.dir	configure task	A variable used in other variables to reference the main project directory
ivy.lib.dir	configure task	${ivy.project.dir}/lib
ivy.lib.dir	configure task	A variable used in other variables to reference the directory in which retrieved artifacts will be put
ivy.distrib.dir	configure task	${ivy.project.dir}/distrib
ivy.distrib.dir	configure task	A variable used in other variables to reference the directory in which artifacts are delivered
ivy.configurations	configure task	*
ivy.configurations	configure task	used as default value of conf attribute of the resolve task
ivy.status	configure task	integration
ivy.status	configure task	used as default value of status attribute of the deliver and publish tasks
ivy.dep.file	configure task	ivy.xml
ivy.dep.file	configure task	used as default value of file attribute of the resolve task
ivy.conf.file	configure task	ivy.xml
ivy.conf.file	configure task	used as default value of file attribute of the configure task
ivy.retrieve.pattern	configure task	${ivy.lib.dir}/[artifact]-[revision].[ext]
ivy.retrieve.pattern	configure task	used as default value of pattern attribute of the retrieve task
ivy.deliver.ivy.pattern	configure task	${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
ivy.deliver.ivy.pattern	configure task	used as default value of deliverpattern attribute of the deliver task
ivy.publish.src.artifacts.pattern	configure task	${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
ivy.publish.src.artifacts.pattern	configure task	used as default value of artifactspattern attribute of the publish task

Patterns

Ivy patterns are used in many dependency resolvers and ivy tasks, and are a simple way to structure the way ivy works.

First let's give an example. You can for instance configure the file system dependency resolver by giving it a pattern to find artifacts. This pattern can be like this:
myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
This pattern indicates that the repository we use is in a directory called myrepository. In this directory we have directories having for name the name of the organisation of the module we look for. Then we have a directory per module, each having for name the name of the module. Then in module directories we find a directory per artifact type (jars, wars, ivys, ...), in which we find artifacts named by the artifact id, followed by an hyphen, then the revision, a dot, and the artifact extension. Not too difficult to understand, isn't it ? That's it, you have understood the pattern concept !

To give a bit more explanation, a pattern is composed of tokens, which are replaced by true values when evaluated for a particular artifact or module. Those tokens are different from variables because they are replaced differently for each artifact, whereas variables are usually given the same value.

You can mix variables and tokens in a pattern:
${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]

Before 0.9, the syntax was the same for variables and tokens (${variable} and ${token}). Since 0.9, token use brackets as delimiters ([token]), which makes them easier to distinguish.

The tokens available depends on where the pattern is used (will it be evaluated with artifacts or modules, for instance). But here are all the tokens currently available:
[organisation] the organisation name
[module] the module name
[revision] the revision name
[artifact] the artifact name (or id)
[type] the artifact type
[ext] the artifact file extension
[conf] the configuration name

Difference between type and extension are explained in ivy file documentation.

Installation

top

Installation

Download the latest version here, unpack the downloaded zip file wherever you want, and copy the ivy jar file in your ant lib directory (ANT_HOME/lib).

If you use ant 1.6.0 or superior, you can then simply go to the src/example/hello-ivy dir and run ant: if the build is successful, you have successfully installed Ivy !

If you use ant 1.5.1 or superior, you have to modify the build files in the examples: - remove the namespace section at their head: xmlns:ivy="antlib:fr.jayasoft.ivy.ant"
- add taskdefs for ivy tasks:

  <taskdef name="ivy-configure" classname="fr.jayasoft.ivy.ant.IvyConfigure"/>
  <taskdef name="ivy-resolve" classname="fr.jayasoft.ivy.ant.IvyResolve"/>
  <taskdef name="ivy-retrieve" classname="fr.jayasoft.ivy.ant.IvyRetrieve"/>
  <taskdef name="ivy-publish" classname="fr.jayasoft.ivy.ant.IvyPublish"/>

- replace ivy:xxx tasks by ivy-xxx
You can now run the build, if it is successful, you have successfully installed Ivy !
If the build is not successful, check the FAQ to see what can be the problem with the ivyrep resolver.

Configuration

top

Ivy Configuration

In order to work as you want it work, ivy need some configuration. Actually, ivy can work with no configuration at all, but in this case it work only with the ivyrep repository. But ivy is able to work in very different contexts. You just have to configure it properly.

Configuration is done through an xml file, usually called ivyconf.xml. To configure ivy from ant, you just have to call the configure task and pass it the path to your configuration file (see configure task documentation for details).

Here is an example of configuration file :

Mainly, the configuration enables to configure the default cache directory used by ivy and the dependency resolvers that it will use to resolve dependencies.

Configuration file structure

The configuration file is structured in some parts and left other open. Indeed each resolver has its own structure, thus it's not the configuration file itself which define the structure for the resolvers.

ivyconf
    properties
    conf
    typedef
    latest-strategies
    resolvers
    conflict-managers
    modules
        module

ivyconf

Tag: ivyconf

Root tag of any ivyconf file.

Child elements

Element	Description	Cardinality
properties	loads properties file as ivy variables	0..n
conf	configures ivy with some defaults	0..1
typedef	defines new types in ivy	0..n
latest-strategies	defines latest strategies	0..n
resolvers	defines dependency resolvers	1..n
conflict-managers	defines conflicts managers	0..n
modules	defines rules between modules and dependency resolvers	0..n

properties

Tag: properties

Loads a properties file into ivy variables. See variables chapter above for details about ivy variables.

Attributes

Attribute	Description	Required
file	a path to a properties file to load	Yes

conf

Tag: conf

Configures some important ivy info: default cache, default resolver, ...

Default cache is used whenever a cache is not provided. It usually points to a directory in your filesystem.

Default resolver is used whenever nothing elese is configured in the modules section of the configuration file. It should give the name of a dependency resolver defined in the resolvers section of the configuration file.

Default latest strategy and conflict manager can also be configured here.

validate indicates if ivy files should generally be validate against xsd or not. This setting is only a default value, and can be overriden :
1) in ant tasks
2) in resolvers
So if there is a setting in the resolver, it always win against all other settings.

checkUpToDate indicates to ivy if it must check date of artifacts before retrieving them (i.e. copying them from cache to another place in your filesystem). Usually it is a good thing to check date to avoid unnecessary copy, even if it's most of the time a local copy.

cacheIvyPattern and cacheArtifactPattern are used to configure the way ivy stores ivy files and artifacts in the cache. Usually you do not have to change this, unless you want to use the cache directly from another tool, which is not recommended.

Attributes

Attribute	Description	Required
defaultCache	a path to a directory to use as default cache	No, defaults to .ivy-cache in user home
defaultResolver	the name of the default resolver to use	No, but all modules should be configured in the modules section if not provided
defaultLatestStrategy	the name of the default latest strategy to use	No, defaults to latest-revision
defaultConflictManager	the name of the default conflict manager to use	No, defaults to latest-revision
validate	Indicates if ivy files should be validated against ivy.xsd or not.	No, defaults to true
checkUpToDate	Indicates if date should be checked before retrieving artifacts from cache	No, defaults to true
cacheIvyPattern	a pattern to indicate where ivy files should be put in cache	No, defaults to [organisation]/[module]/ivy-[revision].xml
cacheArtifactPattern	a pattern to indicate where artifact files should be put in cache	No, defaults to [organisation]/[module]/[type]s/[artifact]-[revision].[ext]

typedef

Tag: typedef

Defines a new type in ivy. Useful to define new dependency resolvers, in particular, but also latest strategies. See how to write and plug your own dependency resolver for details.

Attributes

Attribute	Description	Required
name	the name of the type to define. This name is then used as an xml tag.	Yes
classname	the fully qualified class name of the type to define.	Yes

Latest Strategies

Tag: latest-strategies

Defines a list of latest strategies usable in ivy. Each latest strategy is identified by its name, given as an attribute. The child tag used for the latest strategy must be equal to a name of a latest strategy type (usually added with the typedef tag).

The latest strategies which are always included in ivy (and do not require anything in the configuration file) are:
- latest-time: compares the revisions date to know which is the latest. While this is often a good strategy in terms of pertinence, it has the drawback to be costful to compute with distant repositories. If you use ivyrep, for example, ivy has to ask the http server what is the date of each ivy file before knowing which is the latest.
- latest-revision: compares the revisions as string, using an algorithm close to the one used in the php version_compare function. This algorithm takes into account special meaning of some text. For instance, with this strategy, 1.0-dev1 is considered before 1.0-alpha1, which in turn is before 1.0-rc1, which is before 1.0, which is before 1.0.1.
- latest-lexico: compares the revisions as string, using lexicographic order (the one used by java string comparison).

Child elements

Element	Description	Cardinality
any latest strategy	adds a latest strategy to the list of available strategies	0..n

Dependency Resolvers

Tag: resolvers

Defines a list of dependency resolvers usable in ivy. Each dependency resolver is identified by its name, given as an attribute. The child tag used for the dependency resolver must be equal to a name of a dependency resolver type (either built-in or added with the typedef tag). See buit-in dependency resolvers chapter below for details on available dependency resolvers.

Child elements

Element	Description	Cardinality
any resolver	adds a resolver to the list of available resolvers	1..n

Conflict Managers

Tag: conflict-managers

Defines a list of conflicts managers usable in ivy. Each conflict manager is identified by its name, given as an attribute. The child tag used for the conflict manager must be equal to a name of a conflict manager type (either built-in or added with the typedef tag).

Here is a list of predefined conflicts managers (which do not require anything in the configuration file):
- all: this conflicts manager resolve conflicts by selecting all revisions. Also called NoConflictManager, it does evict any module.
- fixed: this conflict manager always select the same revision
- latest-time: this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
- latest-revision: this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions.

Child elements

Element	Description	Cardinality
any conflict manager	adds a conflict manager to the list of available conflict managers	0..n

modules

Tag: modules

Defines the rules on which resolvers should be used for which modules. The rules are given by defining a module set, using regexp for module organisation and name, and giving the name of the corresponding resolver to use.

Child elements

Element	Description	Cardinality
module	defines a module set rule	1..n

module

Tag: module

Define a resolver application rule. The tag defines a module set, by giving a regexp for organisation and name (for instance, you can use .* to specify all). It also gives the name of the resolver to use for this module set.

Attributes

Attribute	Description	Required
organisation	the name of the organisation to which apply the resolver. May be a regexp.	Yes
name	the name of the module to which apply the resolver. May be a regexp.	Yes
resolver	the name of the resolver to apply. The resolver must have been defined in the resolvers section of the configuration file.	Yes

Built-in dependency resolvers

First of all, if you think that ivy lacks THE dependency resolver you need in your development environment, you can write and plug your own. But first checks the following built-in resolvers to see if you don't find what you want here...

IvyRep resolver

Tag	ivyrep
Handle latest	yes, at least if the repository server is apache based
Handle publish	no

This resolver usually uses ivyrep to find ivy files and ibiblio to find artifacts. However it can be configured to use other similar repositories.

Note that if no ivy file is found on ivyrep, then this resolver behaves like ibiblio resolver. Thus it's always better to use this resolver instead of ibiblio one, which is provided mainly for compatibility reasons.

Attributes

Attribute	Description	Required
name	the name which identify the resolver	Yes
validate	indicates if resolved ivy files should be validated against ivy xsd	No, defaults to true
checkmodified	Indicates if this resolver should check lastmodified date to know if an ivy file is up to date.	No, defaults to ${ivy.resolver.default.check.modified}
ivyroot	the root of the ivy repository.	No, defaults to ${ivy.ivyrep.default.ivy.root}
ivypattern	a pattern describing the layout of the ivy repository.	No, defaults to ${ivy.ivyrep.default.ivy.pattern}
artroot	the root of the artifacts repository.	No, defaults to ${ivy.ivyrep.default.artifact.root}
artpattern	a pattern describing the layout of the artifacts repository.	No, defaults to ${ivy.ivyrep.default.artifact pattern}
latest	The name of the latest strategy to use.	No, defaults to 'default'

IBiblio resolver

Tag	ibiblio
Handle latest	yes, at least if the repository server is apache based
Handle publish	no

This resolver usually uses ibiblio to find artifacts.
Prefer the use of ivyrep resolver which adds ivy file handling to this resolver.

Attributes

Attribute	Description	Required
name	the name which identify the resolver	Yes
validate	indicates if resolved ivy files should be validated against ivy xsd	No, defaults to call setting
root	the root of the artifacts repository.	No, defaults to ${ivy.ibiblio.default.artifact.root}
pattern	a pattern describing the layout of the artifacts repository.	No, defaults to ${ivy.ibiblio.default.artifact.pattern}
latest	The name of the latest strategy to use.	No, defaults to 'default'

File System resolver

Tag	filesystem
Handle latest	yes
Handle publish	yes

This resolver uses the file system to resolve ivy files and artifacts. It presents the advantage to usually have very good performances. Moreover, it is easy to setup using basic OS file sharing mechanism.

The configuration of such a resolver is mainly done through ivy and artifact patterns, indicating where ivy files and artifacts can be found in the file system. You can indicate a list of pattern which will be checked one after the other.

Attributes

Attribute	Description	Required
name	the name which identify the resolver	Yes
validate	indicates if resolved ivy files should be validated against ivy xsd	No, defaults to call setting
checkmodified	Indicates if this resolver should check lastmodified date to know if an ivy file is up to date.	No, defaults to ${ivy.resolver.default.check.modified}
latest	The name of the latest strategy to use.	No, defaults to 'default'

Child elements

Element	Description	Cardinality
ivy	defines a pattern for ivy files, using the pattern attribute	0..n
artifact	defines a pattern for artifacts, using the pattern attribute	1..n

Url resolver

Tag	url
Handle latest	yes with http urls (and apache server) and with file urls, no with other urls
Handle publish	no

This resolver is one of the most generic, in fact most of the previous resolvers can be obtained by a particular configuration of this one. Indeed it uses urls to find ivy files and artifacts. The urls it uses are defined through ivy and artifact children, each giving a pattern to find ivy files or artifacts.

Attributes

Attribute	Description	Required
name	the name which identify the resolver	Yes
validate	indicates if resolved ivy files should be validated against ivy xsd	No, defaults to call setting
checkmodified	Indicates if this resolver should check lastmodified date to know if an ivy file is up to date.	No, defaults to ${ivy.resolver.default.check.modified}
latest	The name of the latest strategy to use.	No, defaults to 'default'

Child elements

Element	Description	Cardinality
ivy	defines a pattern for ivy files, using the pattern attribute	0..n
artifact	defines a pattern for artifacts, using the pattern attribute	1..n

Chain resolver

Tag	chain
Handle latest	depends on sub resolvers
Handle publish	delegates to first sub resolver in chain

This resolver is only a container of a chain of other resolvers. The sub resolvers can be any resolver, including a chain. An attribute enable to indicate if the chain must be iterated after the first found or not (at least when asking for a latest revision). If the chain is iterated, then it's the latest among the ones found that is returned. If the chain is not iterated, then it's the first found which is returned.

Attributes

Attribute	Description	Required
name	the name which identify the resolver	Yes
validate	indicates if resolved ivy files should be validated against ivy xsd	No, defaults to call setting
returnFirst	true if the first found should be returned.	No, defaults to false
latest	The name of the latest strategy to use.	No, defaults to 'default'

Child elements

Element	Description	Cardinality
any resolver	a sub resolver to use	1..n

Dual resolver

Tag	dual
Handle latest	depends on sub resolvers
Handle publish	delegates to ivy sub resolver if artifact to publish is of "ivy" type, to artifact sub resolver otherwise

This resolver delegates its job to one resolver for ivy files and another for artifacts.

Attributes

Attribute	Description	Required
name	the name which identify the resolver	Yes
validate	indicates if resolved ivy files should be validated against ivy xsd	No, defaults to call setting
latest	The name of the latest strategy to use.	No, defaults to 'default'

Child elements

Element	Description	Cardinality
any resolver	two resolvers, the first being the ivy resolver, the second the artifact resolver	2

Ivy Files

top

Ivy files

Ivy use is entirely based on what is called ivy files. Ivy files are xml files, usually called ivy.xml, containing the description of the dependencies of a module, its published artifacts and its configurations.
Here is the simplest ivy file you can write:

<ivy-module version="1.0">
	<info organisation="myorg"
	       module="mymodule"
	/>
</ivy-module>

Since version 0.8, ivy publishes an xslt which help make ivy files more readable. You just have to add a line like this one in your ivy file:

<?xml-stylesheet type="text/xsl" href="http://www.jayasoft.fr/org/ivyrep/ivy-doc.xsl"?>

However, all information is not presented with the xslt (dependency configurations, in particular). And due to security issues, it only works if the ivy file is in the same domain as the xsl... But they are particularly useful to browse the ivy repository.

If you want to see a sample file using almost all possibilities of ivy files, check this one, with or without xslt.

Before beginning the reference itself, it is required to have in mind the terminology defined in the main page of this reference documentation.

For those familiar with xml schema, the schema used to validate ivy files can be found here.

Hierarchical Index

ivy-module
    info
        license
        ivyauthor
        repository
        description
    configurations
        conf
    publications
        artifact
            conf
    dependencies
        dependency
            conf
                mapped
            artifact
                conf
            include
                conf
            exclude
                conf
    conflicts
        manager

ivy-module

Tag: ivy-module

Root tag of any ivy-file.

Attributes

Attribute	Description	Required
version	the version of the ivy file specification - should be '1.0' with current version of ivy	Yes

Child elements

Element	Description	Cardinality
info	contains information about the described module	1
configurations	container for configuration elements	0..1
publications	container for published artifact elements	0..1
dependencies	container for dependency elements	0..1
conflicts	section to configure the conflict managers to use	0..1

info

Tag: info Parent: ivy-module

Gives information about the module this ivy file describe

Attributes

Attribute	Description	Required
organisation	the name of the organisation that is the owner of this module.	Yes
module	the name of the module described by this ivy file.	Yes
revision	the revision of this module.	No, but it's a good practice to set it with delivered ivy files
status	the status of this module. See terminology section for details	No, default to 'integration'
publication	the date of publication of this module. It should be given in this format: yyyyMMddHHmmss	No, but it's a good practice to set it with delivered ivy files

Child elements

Element	Description	Cardinality
license	contains information about the licenses of the described module	0..n
ivyauthor	describes who has contributed to write the ivy file	0..n
repository	describes on which public repositories this module can be found	0..n
description	describes how to use the module	0..1

license

Tag: license Parent: info

Gives information about a license of the described module.

Attributes

Attribute	Description	Required
name	the name of the license. Try to respect spelling when using a classical license.	Yes
url	an url pointing to the license text.	No, but it's a good practice to indicate it

Ivy Author

Tag: ivyauthor Parent: info

Gives information about who has contributed to write this ivy file. It does NOT indicate who is the author of the module itself.

Attributes

Attribute	Description	Required
name	the name of the author, as a person or a company.	Yes
url	an url pointing to where the author can bea reached.	No, but it's a good practice to indicate it

Public Repository

Tag: repository Parent: info

Gives information about a public repository where the module can be found. This information is given as an indication, repositories being able to be down over time.

Attributes

Attribute	Description	Required
name	the name of the repository. Try to respect spelling for common repositories (ibiblio, ivyrep, ...)	Yes
url	an url pointing to the repository.	Yes
pattern	an ivy pattern to find modules on this repository	No, but it's recommended to indicate it.
ivys	true if ivy file can be found on this repository	No, defaults to false.
artifacts	true if module artifacts can be found on this repository	No, defaults to false.

Description

Tag: description Parent: info

Describes the current module. This tag is the only one which can contain free text, including html. It is used to describe the module itself, usually in a single short phrase (it is not meant to replace the module description on the corresponding web site), and then gives all information necessary to use the module, especially information about public configurations, how and when to use them.

Attributes

Attribute	Description	Required
homepage	the url of the homepage of the module	No, but it's recommended to indicate it.

configurations

Tag: configurations Parent: ivy-module

Container for configuration element. If this container is not present, it is assumed that the module has one public configuration called 'default'.

Child elements

Element	Description	Cardinality
conf	declares a configuration of this module	1..n

configuration declaration

Tag: conf Parent: configurations

Declares a configuration of this module. As described in the reference page, a configuration is a way to use or construct a module. Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server). Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those differents ways to use or build a module are called in ivy configurations.

The conf element in the configurations section declares one configuration. This declaration gives the name of the configuration declared, its visibility and the other configurations of the module it extends.

Visibility is used to indicate whether or not a configuration can be used from other modules depending on this one. Thus a private configuration is only used for internal purpose (maybe at build time), and other modules cannot declare to depend on it.

A configuration can also extend one or several other ones of the same module. When a configuration extends another one, then all artifacts required in the extended configuration will also be required in the configuration that extends the other one. For instance, if configuration B extends configuration A, and if artifacts art1 and art2 are required in configuration A, then they will be automatically required in configuration B. On the other hand, artifacts required in configuration B are not necessarily required in configuration A.
This notion is very helpful to define configurations which are similar with some differences.

Attributes

Attribute	Description	Required
name	the name of the declared configuration	Yes
description	a description for the declared configuration	No
visibility	the visibility of the declared configuration. 'public' means that this configuration can be used by other modules, while 'private' means that this configuration is used only in the module itself, and is not exposed to other modules	No, defaults to public
extends	a comma separated list of configurations of this module that the current configuration extends	No, defaults to none
deprecated	indicates that this conf has been deprecated by giving the date of the deprecation. It should be given in this format: yyyyMMddHHmmss	No, by default the conf is not deprecated

publications

Tag: publications Parent: ivy-module

Container for artifact elements, used to describe the artifacts published by this module. If this container is not present, it is assumed that the module has one artifact, with the same name as the module, and published in all module configurations.
Thus if you have a module which publishes no artifacts (a sort of virtual module, made only to integrate several other modules as a whole), you have to include a publications element with no artifact sub element.

Child elements

Element	Description	Cardinality
artifact	declares a published artifact for this module	0..n

published artifact

Tag: artifact Parent: publications

Declares an artifact published by this module. This is especially useful for other modules dependending on this one. They thus get all published artifacts belonging to the configurations asked. Indeed, each published artifact declares in which public configuration it is published. Thus a module depending on this module only get artifacts marked with the asked configurations, taking into account configurations extension (see configuration declaration).

The configurations in which an artifact is published can be configured in two ways:
- conf attribute on artifact element
- conf subelement
The twos are equivalent, it is only a matter of preference. However, do not mix both for one artifact.

Attributes

Attribute	Description	Required
name	the name of the published artifact. This name must not include revision.	Yes
type	the type of the published artifact. It's usually its extension, but not necessarily. For instance, ivy files are of type 'ivy' but have 'xml' extension	Yes
ext	the extension of the published artifact	No, defaults to type
conf	comma separated list of public configurations in which this artifact is published. '*' wildcard can be used to designate all public configurations of this module	No, defaults to 'default' if neither conf attribute nor conf children element is given

Child elements

Element	Description	Cardinality
conf	indicates a public configuration in which this artifact is published	0..n

artifact configuration

Tag: conf Parent: artifact

Indicates a public configuration in which enclosing artifact is published.

Attributes

Attribute	Description	Required
name	the name of the module public configuration in which this artifact is published. '*' wildcard can be used to designate all public configurations of this module	Yes

dependencies

Tag: dependencies Parent: ivy-module

Container for dependency elements, used to describe the dependencies of this module. If this container is not present, it is assumed that the module has no dependency at all.

Child elements

Element	Description	Cardinality
dependency	declares a dependency for this module	1..n

dependency

Tag: dependency Parent: dependencies

Declares a dependency for this module. A dependency is described by the module on which the current module depends (identified by its name, organisation and revision), and a mapping of configurations.

The revision can be given as a fixed one (1.5.2, for instance) or as a latest one. Two possibilities are offered for the moment:
- latest.integration, which selects the latest revision of the dependency module.
- end the revision with a +, which selects the latest sub-revision of the dependency module. For instance, if the dependency module exists in revision 1.0.3, 1.0.7 and 1.1.2, "1.0+" will select 1.0.7.
The way to determine which revision is the "latest" between two is configurable through the use of pluggable LatestStrategy. See ivy main concepts for details about this.
This mapping indicates which configurations of the dependency are required in which configurations of the current module, also called master configurations.

There are several ways to declare this mapping of configurations, choose depending more on preference than on possibilities. Try to not mix usage in a single dependency element: do not use both nested and inline mapping declaration.

The first way to declare this mapping is called the inline mapping. It is maybe the less natural at first, but it's powerful and concise. Inline mapping can take several forms.

- Specify one configuration name. This means that in this master configuration the same dependency configuration is needed. For instance, if the current module has defined a configuration named 'runtime', and the dependency too, then having an inline mapping configuration set to 'runtime' means that in the runtime master configuration the runtime dependency configuration is required.

- Specify a configuration mapping using the '->' operator separating a comma separated list of master configurations (left operand) of a comma separated list of dependency configurations (right operand). In this case, all specified dependency configurations are required in all specified master configurations. For instance, 'A, B, C -> E, F' means that dependency configurations E & F are required in master configurations A, B and C.
Note that you can use the wildcard '*' as a configuration name, meaning that all configurations (either master or dependency public ones depending on the side) are wanted. For instance, '* -> B, C' means that B & C dependency configurations are required in all master configurations

- Specify a semi-column separated list of any of the previous specs. In this case, it is the union of the mapping which is kept. For instance, 'A -> B; * -> C' means that B conf is needed in A conf and C conf is need in all master conf... so both B & C dep conf are required in A master conf

If you prefer more verbose mapping declaration, everything is also possible with sub elements mapping declaration.

Moreover, the dependency element also supports an artifact restriction feature (since 0.6). See dependency artifact restriction for details.

Finally, the dependency element also supports an a force attribute (since 0.8), which gives an indication to conflicts manager to force the revision of a dependency to the one given here.
See conflicts manager for details.

Attributes

Attribute	Description	Required
org	the name of the organisation of the dependency.	No, defaults to the master module organisation
name	the module name of the dependency	Yes
rev	the revision of the dependency. Use 'latest.integration' to get the latest version of the dependency. You can also end the revision asked with a '+' to get the latest matching revision. Both latest works only with some dependency resolvers (see configuration)	Yes
force	a boolean to give an indication to conflict manager that this dependency should be forced to this revision (see conflicts manager)	No, defaults to false
conf	an inline mapping configuration spec (see above for details)	No, defaults to '->' if neither conf attribute nor conf children element is given

Child elements

Element	Description	Cardinality
conf	defines configuration mapping has sub element	0..n
artifact / include	defines artifacts inclusion - use only if you do not control dependency ivy file	0..n
exclude	defines artifacts exclusion - use only if you do not control dependency ivy file	0..n

master to dependency configuration mapping

Tag: conf Parent: dependency

Describes a configuration mapping for a dependency. See also the inline configuration mapping in dependency element.

Attributes

Attribute	Description	Required
name	the name of the master configuration to map. '*' wildcard can be used to designate all configurations of this module	Yes
mapped	a comma separated list of dependency configurations to which this master configuration should be mapped	No, default to the same configuration as master one, unless nested mapped elements are specified

Child elements

Element	Description	Cardinality
mapped	map dependency configurations for this master configuration	0..n

mapped dependency configuration

Tag: mapped Parent: conf

Describes a mapped dependency configuration for a master configuration.

Attributes

Attribute	Description	Required
name	the name of the dependency configuration mapped. '*' wildcard can be used to designate all configurations of this module	Yes

dependency artifact include

Tag: artifact Parent: dependency
Tag: include Parent: dependency

This feature gives you more control on a dependency for which you do not control its ivy file. It enables two things:
- restrict the artifacts required by including only the artifacts given here, even if configuration does not a good separation of published artifacts
- specify the artifacts required, if the dependency has no ivy file. Indeed, when a module has no ivy file, it is assumed that it publishes exactly one artifact having the same name as the module itself. But when this module publishes more artifacts, or simply does not respect the name rule, and if you cannot deliver an ivy file for it (because you do not control the repository, for instance - think about maven ibiblio repository, to give no name), then this feature let you specify the artifacts names you want to retrieve.

This feature is handled by two tags, artifact and include, which are stricly equivalent. However, it is a good practive to use the artifact tag to specify the artifact required, and the include tag to specify artifact inclusion among dependency published ones.

Each artifact restriction can be given in the context of particular master configurations. By default, if no configuration is specified, artifacts restriction apply to all master configurations. But you can specify that a restriction applies only to one or several master configurations, using either inline or nested conf specification. In this case, do not forget that if you do not specify any restriction for a particular configuration, then no restriction will apply for this configuration and it will be resolved not taking into account any restriction.

For instance, imagine you have A, B & C master configurations. If you restrict to art1 in A & B and art2 in A, then C will not be restricted at all, and will thus get all artifacts of all dependency configurations if you do not specify a configuration mapping. To prevent this, you have to specify a configuration mapping for the dependency, mapping only A & B to some or all dependency configurations.
Example:

<dependency org="yourorg" name="yourmodule9" rev="9.1" conf="A,B->default">
	<artifact name="art1" type="jar" conf="A,B"/>
	<artifact name="art2" type="jar" conf="A"/>
</dependency>

Attributes

Attribute	Description	Required
name	the name of an artifact of the dependency module to add to the include list, or a regexp matching this name	No, defaults to .*
type	the type of the artifact of the dependency module to add to the include list, or a regexp matching this name	No, defaults to .*
ext	the extension of the artifact of the dependency module to add to the include list, or a regexp matching this name	No, defaults to type
conf	comma separated list of the master configurations in which this artifact should be included. '*' wildcard can be used to designate all configurations of this module	No, defaults to '*', unless nested conf are specified

Child elements

Element	Description	Cardinality
conf	configuration in which the artifact should be included	0..n

dependency artifact include configuration

Tag: conf Parent: artifact

Specify a configuration in which the enclosing artifact inclusion should be included.

Attributes

Attribute	Description	Required
name	the name of the master configuration in which the enclosing artifact should be included	Yes

dependency artifact exclude

Tag: exclude Parent: dependency

This feature gives you more control on a dependency for which you do not control its ivy file. It enables to restrict the artifacts required, by excluding artifacts being published by the dependency, even if configuration does not a good separation of published artifacts

The same principle concerning configuration as for include applies to this exclude feature (see above the include feature).

Note that exclusion is always done AFTER inclusion has been done.

Attributes

Attribute	Description	Required
name	the name of an artifact of the dependency module to add to the exclude list, or a regexp matching this name	No, defaults to .*
type	the type of the artifact of the dependency module to add to the exclude list, or a regexp matching this name	No, defaults to .*
ext	the extension of the artifact of the dependency module to add to the exclude list, or a regexp matching this name	No, defaults to type
conf	comma separated list of the master configurations in which this artifact should be included. '*' wildcard can be used to designate all configurations of this module	No, defaults to '*', unless nested conf are specified

Child elements

Element	Description	Cardinality
conf	configuration in which the artifact should be included	0..n

dependency artifact exclude configuration

Tag: conf Parent: artifact

Specify a configuration in which the enclosing artifact exclusion should be included.

Attributes

Attribute	Description	Required
name	the name of the master configuration in which the enclosing artifact should be excluded	Yes

Conflicts Manager

Tag: conflicts Parent: ivy-module

Container for conflict manager elements, used to indicate how conflicts should be resolved for this module.

A conflict occurs when two revisions of the same module are required. This can happen in several cases, but the more often it is due to transitive dependencies: a module depends on A rev 1.0 and on B rev 2.0, and B depends on A rev 1.1. Then we say there is a conflict on A.

To resolve the conflict, ivy uses conflicts managers. A conflict manager is able to select, among a list of module revisions in conflict, a list of revisions to keep. Yes, it can selects a list of revision, even if most conflicts manager select only one revision. But in some cases you will need to keep several revisions, and load in separate class loaders, for example.

Conflicts manager can be defined in each ivy file. Conflicts are thus resolved recursively, each module being responsible to resolve conflicts of its dependencies.

Conflicts manager are declared by module, this means that you can declare a different conflict manager for each dependency. Moreover, conflicts manager being in a separate section in the ivy file (and not in the dependencies section), you can declare them for a set of modules (using regular expression, see manager), and you can declare them for non direct dependencies. Imagine a module depends on A and B, A depends on C rev 1.0 and B depends on C rev 2.0. Then there is conflict on C which must be solved by the module, even if the module has no direct dependency on C. This is possible with the conflict manager handling of ivy.

Ivy comes with 4 built-in conflicts manager, but you can also plug your own:
- all: this conflicts manager resolve conflicts by selecting all revisions. Also called NoConflictManager, it does evict any module.
- fixed: this conflict manager always select the same revision
- latest-time: this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
- latest-revision: this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions as defined by the latest-revision strategy (see Latest Strategies for details).

The two "latest" conflicts manager also take into account the force attribute of the dependencies. Indeed direct dependencies can declare a force attribute (see dependency), which indicates the the revision given in the direct dependency should be prefered over indirect dependencies.

Conflicts manager are used during the resolve operation, i.e. when ivy analyse the graph of dependencies and download corresponding ivy files and artifacts. The fact to manage conflict at resolve time enables to minimize downloads: when a module is evicted by a conflict manager, it is not downloaded.

There are two things optimized during conflict resolution: download of artifacts and download of ivy files. The first is always ensured by ivy, i.e. artifacts of a module evicted will never be downloaded. The second is not as simple to handle because to know what are the conflicts ivy needs to know the dependency graph, and to know the dependency graph, it has to download ivy files. But ivy is highly optimized on this too, and it tries to evict modules as soon as possible.
That's why the order of dependencies is important for download optimization. Indeed ivy traverses the dependency graph in the order in which dependencies are declared in the ivy files, and each time it encounters a dependency on a module, it first check if there is a conflict on this module, and if this is the case, it asks the conflict manager to resolve the conflict. Then if the module is evicted, it does not download its ivy file, and the whole branch is not traversed, which can saves a lot of time.

If this container is not present, a default conflict manager is used for all modules. The current default conflict manager is the "latest-revision" conflict manager.

Child elements

Element	Description	Cardinality
manager	declares a conflict manager for this module	1..n

Conflict Manager

Tag: manager Parent: conflicts

Specify a a conflict manager for one or several dependencies.
The way to specify a conflict manager is by giving indication to which dependencies the conflict manager applies (by giving organisation and module names or name regexp), and then specifying the conflict manager, either by giving its name or by specifying a fixed revision list, in which case a fixed conflicts manager is used.

See Conflicts Manager for details on conflicts manager in general.

Attributes

Attribute	Description	Required
org	the name, or a regexp matching the name of organisation to which this conflict manager should apply	No, defaults to .* (match all)
module	the name, or a regexp matching the name of module to which this conflict manager should apply	No, defaults to .* (match all)
name	the name of the conflict manager to use	Exactly one of two
rev	a comma separated list of revisions this conflict manager should select	Exactly one of two

Using ivy

top

Using Ivy

The main and most frequent way to use ivy is from an ant build file. However, ivy can also be called as a standalone application.

If you use ant version 1.6.0 or superior, you just have to add ivy namespace to your project (xmlns:ivy="antlib:fr.jayasoft.ivy.ant" attribute of your project tag), and you can call ivy tasks.

If you use ant 1.5.1 or superior, you have to define the tasks in your build file:

  <taskdef name="ivy-configure" classname="fr.jayasoft.ivy.ant.IvyConfigure"/>
  <taskdef name="ivy-resolve" classname="fr.jayasoft.ivy.ant.IvyResolve"/>
  <taskdef name="ivy-retrieve" classname="fr.jayasoft.ivy.ant.IvyRetrieve"/>
  <taskdef name="ivy-deliver" classname="fr.jayasoft.ivy.ant.IvyDeliver"/> 
  <taskdef name="ivy-publish" classname="fr.jayasoft.ivy.ant.IvyPublish"/>

Then you can use the tasks, but check their name, following samples assume you use the ivy namespace (ivy:xxx tasks), whereas with ant 1.5 you cannot use namespace, and should therefore use ivy-xxx tasks if you have followed the taskdefs above.

If you use an ant version lower than 1.5.1, you can not use the ivy tasks... you should then call ivy as any external program.

Calling ivy as a standalone program

In the case you want to call ivy as a standalone program (outside from ant), you have to put commons-cli 1.0 and its dependencies in your classpath.

Then here is how to call it:

java fr.jayasoft.ivy.Main -?

It will indicate you what can be given as argument. Here are some examples:

java fr.jayasoft.ivy.Main

calls ivy with default configuration using ivy.xml in the current dir

java fr.jayasoft.ivy.Main -conffile path/to/myivyconf.xml -ivyfile path/to/myivy.xml

calls ivy with given ivyconf file using given ivy file

Calling ivy from ant: first steps

Once your build file is ok to call ivy tasks, the simplest way to use ivy is to call the ivy retrieve task with no parameters:

<ivy:retrieve />

This calls ivy with default values, which might be ok in several projects. In fact, it is equivalent to:

Those 3 tasks follow the 3 main steps of ivy retrieving dependencies process:

First the configure task tells it how it can find dependencies giving it a path to an xml configuration file.
Then the resolve task actually resolve dependencies described by an ivy file, and put those dependencies in the ivy cache (a directory configured in the configuration file).
Finally the retrieve task copies dependencies from the cache to anywhere you want in your file system. You can then use those dependencies to make your classpath with standard ant paths.

To understand more accurately the behaviour of ivy tasks, one should know that a property file is loaded in ant by ivy at the beginning of the configure call. This property file contains the following properties:

ivy.project.dir = ${basedir}
ivy.lib.dir = ${ivy.project.dir}/lib
ivy.build.artifacts.dir = ${ivy.project.dir}/build/artifacts
ivy.distrib.dir = ${ivy.project.dir}/distrib
	
ivy.configurations = *
ivy.resolver.default.check.modified = false
ivy.status = integration
ivy.dep.file = ivy.xml
ivy.conf.file = ivyconf.xml
ivy.retrieve.pattern = ${ivy.lib.dir}/[artifact]-[revision].[ext]
ivy.deliver.ivy.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
ivy.publish.src.artifacts.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]

ivy.ivyrep.default.ivy.root = http://www.jayasoft.fr/org/ivyrep/
ivy.ivyrep.default.ivy.pattern = [organisation]/[module]/ivy-[revision].xml
ivy.ivyrep.default.artifact.root = http://www.ibiblio.org/maven/
ivy.ivyrep.default.artifact.pattern = [module]/[type]s/[artifact]-[revision].[ext]

ivy.ibiblio.default.artifact.root = http://www.ibiblio.org/maven/
ivy.ibiblio.default.artifact.pattern = [module]/[type]s/[artifact]-[revision].[ext]

Example

Here is a more complete example of build file using ivy:

Tasks reference documentation

configure

The configure task is used to configure ivy with an xml configuration file.

See configuration for details about the configuration file itself.

Note for developers:
After the call to this task, a reference to the configured ivy instance used by all subsequent ant tasks is put in the ant project, under the id "ivy.instance".

Attribute	Description	Required
file	path to the configuration file to use	No. If a file is provided, url is ignored. If none are provided, then it attempts to find a file at ${ivy.conf.file}, and if this file does not exist, it uses a default configuration file
url	url of the configuration file to use
host	http authentication host	No, unless authentication is required
realm	http authentication realm
username	http authentication user name
passwd	http authentication password

HTTP Authentication

Note: HTTP Authentication can be used only if commons-httpclient.jar is in your classpath If any of the url you use in ivy (especially in dependency resolvers) need http authentication, then you have to provide the host, realm, username and passwd attributes of the configure task. These settings will then be used in any further call to ivy tasks.

Examples

Simplest configuration

<ivy:configure />

Use either ${ivy.conf.file} if it exists, or the default configuration file

Configure with a file

<ivy:configure file="myconffile.xml" />

Configure with an url

<ivy:configure url="http://mysite.com/myconffile.xml" />

resolve

The resolve task actually resolve dependencies described in an ivy file, and put the resolved dependencies in the ivy cache.
If configure has not been called before resolve is called, a default configuration will be used (equivalent to call configure with no attributes).

After the call to this task, four properties are set in ant:
ivy.organisation: set to the organisation name found in the ivyfile which was used for resolve
ivy.module: set to the module name found in the ivyfile which was used for resolve
ivy.revision: set to the revision name found in the ivyfile which was used for resolve, or a generated revision name if no revision was specified in the file
ivy.resolved.configurations: set to the comma separated list of configurations resolved

Note for developers:
After the call to this task, a reference to the module descriptor resolved is put in the ant project under the id "ivy.resolved.descriptor".

Attribute	Description	Required
file	path to the ivy file to use for resolution	No. Defaults to ${ivy.dep.file}
conf	a comma separated list of the configurations to resolve	No. Defaults to ${ivy.configurations}
haltonfailure	true to halt the build on ivy failure, false to continue	No. Defaults to true
showprogress	true to show dots while downloading, false otherwise	No. Defaults to true
validate	true to force ivy files validation against ivy.xsd, false to force no validation	No. Defaults to default ivy value (as configured in configuration file)

retrieve

The retrieve task copies resolved dependencies anywhere you want in your file system.
If no resolve has been called before retrieve is called, a default resolve is called (equivalent to a call to resolve with no attributes).

Attribute	Description	Required
pattern	the pattern to use to copy the dependencies	No. Defaults to ${ivy.retrieve.pattern}
conf	a comma separated list of the configurations to retrieve	No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
haltonfailure	true to halt the build on ivy failure, false to continue	No. Defaults to true
validate	true to force ivy files validation against ivy.xsd, false to force no validation	No. Defaults to default ivy value (as configured in configuration file)

deliver

Delivers a resolved ivy file of the current module, and possibly do recursive delivery of dependencies.
This task does two main things:
- deliver a resolved ivy file of the current module, based upon the last resolve done. In the resolved ivy file, no latest version of any kind subsist, so the ivy file can be used later safely to obtain the same dependencies (providing that a revision uniquely identifies a module, which should be the case for proper ivy use). - do recursive delivery. This is done only if a deliver target is given to the deliver task.
If a deliver target is set, then it is called for each dependency which has not a suffisant status compared to the deliver status set for this task. This means that if you deliver an integration revision, no recursive delivery will be done. If you deliver a milestione revision, deliver target will be called with each integration dependency. Finally, if you deliver a release revision, then deliver target will be called with each integration and milestone dependency.

The deliver target is called with the following properties available:
* dependency.name : the name of the dependency to recursively deliver
* dependency.published.status : the status to which the dependency should be delivered
* dependency.published.version : the revision to which the dependency should be delivered
* dependency.version : the revision of the dependency that should be delivered (the one that was retrieved during last resolve)
Note that both dependency.published.status and dependency.published.version are in fact asked to the user via standard ant input. the delivered ivy file will update its dependency revisions with those given here.

Attribute	Description	Required
deliverpattern	the pattern to use for ivy file delivery	No. Defaults to ${ivy.deliver.ivy.pattern}
pubrevision	the revision to use for the publication	No. Defaults to the ${ivy.deliver.revision}
pubdate	the publication date to use for the publication. This date should be either 'now', or a date given with the following pattern: yyyyMMddHHmmss	No. Defaults to 'now'
status	the status to use for the publication	No. Defaults to ${ivy.status}
delivertarget	the target to call for recursive delivery	No. No recursive delivery is done by default
validate	true to force ivy files validation against ivy.xsd, false to force no validation	No. Defaults to default ivy value (as configured in configuration file)

publish

Publishes the current modules artifacts.

This task is meant to publish the declared published artifacts of the current module to a repository.
The repository is given through the name of a resolver declared in current ivy configuration. See configuration for details about resolver supporting artifact publishing.
It also publishes the delivered ivy file (except if you don't want), and even deliver it if it has not been done with a previous deliver call. That's why this task takes some parameters useful only for delivery.

Attribute	Description	Required
artifactspattern	the pattern to use to find artifacts to publish	No. Defaults to ${ivy.publish.src.artifacts.pattern}
resolver	the name of the resolver to use for publication	Yes
pubrevision	the revision to use for the publication	No. Defaults to the ${ivy.deliver.revision}
validate	true to force ivy files validation against ivy.xsd, false to force no validation	No. Defaults to default ivy value (as configured in configuration file)
publishivy	True to publish delivered ivy file, false otherwise	No. Defaults to true
warnonmissing	True to warn when artifacts to be published are missing	No. Defaults to true
haltonmissing	True to halt build when artifacts to be published are missing	No. Defaults to true
deliverivypattern	the pattern to use for ivy file delivery, if necessary	No. Defaults to the value of artifactspattern
pubdate	the publication date to use for the delivery, if necessary. This date should be either 'now', or a date given with the following pattern: yyyyMMddHHmmss	No. Defaults to 'now'
status	the status to use for the delivery, if necessary	No. Defaults to ${ivy.status}
delivertarget	the target to call for recursive delivery	No. No recursive delivery is done by default

cachepath

Constructs an ant path consisting of artifacts in ivy cache for a configuration.

This task is usually used after a resolve, and can be used instead of retrieve. Note that this task does not rely on retrieve, because built path is made of artifacts direcly in ivy cache.

Please prefer the use of retrieve + standard ant path creation, which make your build more independent from ivy (once artifacts are properly retrieved, ivy is not required any more).

Built path is registered in ant with a given id, and can thus be used like any other ant path using refid.

Attribute	Description	Required
pathid	the id to reference the built path	Yes
conf	a comma separated list of the configurations to put in the created path	No. Defaults to the configurations resolved by the last resolve call, or * if no resolve was explicitly called
haltonfailure	true to halt the build on ivy failure, false to continue	No. Defaults to true
validate	true to force ivy files validation against ivy.xsd, false to force no validation	No. Defaults to default ivy value (as configured in configuration file)

report

Generates reports of dependecy resolving. One report per configuration is generated, but all reports generated together are hyperlinked one to each other.

This task should be used only after a call to resolve, even if the call was not done during the same ant build.
In fact, this task uses xml report generated by resolve in cache. So if you call resolve on a module for a given configuration, you can call report safely on this module and this configuration as long as you do not clean your ivy cache.

If you want to have an idea of what reports look like, check this very simple example. The task also generates a graphml file which can be loaded with the free yEd graph editor. Then following a few simple steps you can obtain a graph like this one.

Attribute	Description	Required
todir	the directory to which reports should be generated	Yes
graph	true top generates graphml files, false otherwise	No, defaults to true
conf	a comma separated list of the configurations for which a report should be generated	No. Defaults to the configurations resolved by the last resolve call (during same ant build), or ${ivy.resolved.configurations} if no resolve was called
organisation	the name of the organisation of the module for which report should be generated	No, unless no resolve was called during the build. Defaults to last resolved module organisation.
module	the name of the module for which report should be generated	No, unless no resolve was called during the build. Defaults to last resolved module.
validate	true to force ivy files validation against ivy.xsd, false to force no validation	No. Defaults to default ivy value (as configured in configuration file)

var

Sets a variable (by name and value), or set of variables (from file or url) in ivy.
Variables are case sensitive.

Contrary to ant properties, ivy variables are mutable. But a problem with this is that you do not control when variables are substituted, and usually it is done as soon as possible. So changing the value of a variable will have no effect if it has already been substituted. Consequently, using this task is NOT recommended. See reference page for details about ivy variables.

Attribute	Description	Required
name	the name of the variable to set	No
value	the value of the variable to set	Yes when using the name attribute
file	the filename of the property file to load as ivy variables	One of these, when not using the name attribute
url	the url from which to read ivy variables	One of these, when not using the name attribute
prefix	Prefix to apply to variables. A "." is appended to the prefix if not specified.	No

Products Comparison

top

Products comparison - last updated 2005-04-21

We are frequently asked how Ivy can be compared to other dependency management tools. Here is a short matrix summing up a comparison of the products handling dependency management that we have heard about.

Obviously, this comparison can not be objective and may be inacurrate for some products, but we have tried to do it with as little subjective judgement as possible.

Product	Maven ibiblio compatibility	Ant integration	Continuous integration	Transitive dependencies	Flexibility	Maturity	License
Ivy	++	++	++	++	++	+	BSD
Maven	+++	--	+	--	+	+++	Apache Software License
Maven2	++ *	-	++	+	+	---	Apache Software License
HttpUnit Dependencies	++	++	+	--	+	-	MIT License
Savant	--	++	--	+	++	++	Other

Some Explanations

Maven ibiblio compatiblity

The use of the maven ibiblio repository is interesting because it is already filled with many projects. Benefiting from this repository is thus a plus.

On this feature, the best is obviously maven itself, since this repository has been built at the initiative of the project. Maven2 is a bit special, because it changes the layout of the repository compared to maven1, and thus a new repository is available. But everything in the first repository seems to be synced in the second, and how could we say that maven is not 100% compatible with maven repository ;-).
The dependencies task of http-unit is also very good, one of the main aim of the project being to bring this repository to ant users. Savant does not provide such a compatibility.
Ivy, since its version 0.6, can be considered almost as good as the dependencies task. It provides a built-in ibiblio repository compatibility, and the limitation of not being able to say that you depend on a particular jar of a module has been deleted by the 0.6+ feature of artifacts restriction. For sure, the use of ivy files for dependencies is still heavily recommended, the advantage of this technique being that once an ivy file has been written, you can reuse the module easier, and it's the aim of Ivy.

Ant integration

Ant is the most used build tool in the java community. Being well integrated with it is a real plus.

On this feature, maven, which is also a build tool by its own and not only a dependency management tool, is the only one to distinguish itself (even if you can call ant tasks from maven, the opposite is not easily the case). Maven2 will propose ant tasks for its dependency management feature, so a good step is taken in this direction. But for the moment it's not publicly available. For the others, integration is at the same level. The dependencies task and Savant could be claimed to be more integrated, since the dependencies are declared in the build file itself and they produce paths or filesets of the dependencies.
Ivy, for its part, has taken the party to be less intrusive in the build file:
- The dependencies are described in a separate file. The advantage of being separated is that this dependency file can be reused for dependency of dependency management, and that it can have its own life in your source control management, in particular.
- It lets you build your filesets and paths by your own. The advantage is that if you already have a build file, you can simply ask Ivy to put your dependencies at the place they used to be, and that's all, you have migrated to Ivy. Moreover, you can still benefit of all the power of ant filesets and paths declaration.
- Since 0.8, it is able to build a path for you with the cachepath task.

Continuous integration

A dependency management tool is the most util when your dependencies change often, and this is especially the case in a continuous integration environment, where your dependencies can change of version very often.

On this point, as far as I know, Savant do not allow to automatically change the version you use when a new is released.
Maven provides a SNAPSHOT feature, which enables continuous integration only if the component you depend on publishes SNAPSHOT versions. And you can by no way know which was really that version, in order to get that particular version on a later time.
I have for the moment very few information on Maven2 on this subject, but it will at least do what maven did.
The dependencies task say you can tell that you depend on the latest version, and that it is then the responsibility of the Repository to get it... but I haven't found more information on their web site. Maybe it uses the same principle as Maven...
Ivy uses pluggable latest strategies to find the latest version, so that the component you depend on has nothing special to do. Moreover, it produces a report in which it tells which version has been retrieved, so that you can easily know the environment of the component you are building. Finally, it can even produce an ivy file with all latest revisions resolved to a fixed one, so that you can use it to reproduce the same environment even later, when new versions of the dependencies will have been built.

Transitive dependencies

Transitive dependencies management, also known as dependencies of dependencies management, let you reuse more easily complex components which have themselves dependencies, and help you manage conflicts between dependencies.
Maven and the dependencies task does not provide this feature at all.
Maven2 will provide this feature, but few doc is avaialble for the moment. It seems that it will be handled by declaring a dependency on the pom of another project. I have no information on how filter will be applied to the transitive dependencies.
Savant actually manage transitive dependencies, but you automatically get all dependencies of your dependencies, not being able to filter them easily.
Ivy provides this feature, and, with its concept of configurations, let you choose the set of artifacts of your dependencies you really need. You can even use fine graine filters (include/exclude) to adjust what you want. Finally, its unique configurable conflict manager let you manage conflicts the way you want, even if the default strategy works in most cases so that no special configuration is required.

Flexibility

Is the dependency management tool able to adapt to your environment, or have you to follow its rules ? It's a matter of flexibility, and it's hard to evaluate.
As far as I know, Maven dependency management is based on a rigid structure of repository you have to follow, unless you specify for each jar where it can be found, which does not really let you have a repository structure of your choice. Maven2 will certainly follow the same philosophy. The dependencies task has the same limitation, unless you create your own implementation of Repository. Savant seems to provide a lot of flexibility, but it also seems quite hard to configure.
Ivy is extremely flexible:
- comes out of the box with two main ways to find dependencies (filesystem based and url based)
- let you configure your repository layout with very simple to define patterns
- let you use multiple repositories, chaining them or defining which repository to use for which modules or group of modules
- let you choose where you artifacts are copied in your file system, with or without version in the name, and structured the way you want, all with the same simple pattern principle
- let you define reusable configurations of your component, since a same component does not have the dependencies at build time or runtime, or when deployed in a server or as a standalone application, etc.

Maturity

On this point, two products are now quite old and can be considered mature: Maven and Savant. On the other hand, the dependencies task has published its first version (0.1) on september 2004, and, at the time of this writing, no version has been published since their 0.4 in december 2004.
Maven2 is still in alpha, with no public download and very few documentation.
Finally, Ivy as published its first public version (0.5) on january 2005 after several months of use in our company. After several months of user driven development and testing, and after several weeks of release candidates cycles, it is finally close to its first stable release: 1.0. It's still far from being "mature", but backward compatibilty will be assured with future versions, and the user communitity grows from day to day. And if you want to have a look of what others think of Ivy, check the links section.

Feel free to comment the comparison on this page if you think that we have forgotten some points or missed features of the other products.
FAQ
top
Frequently Asked Questions

I have a problem with ivy, how can I get more information about what it is doing ?
The first thing to do for trouble shooting ivy is to increase your ant message level. Use -verbose to have verbose messages, and -debug or -d to have debug messages.
Ivy seems to fail connecting to ibiblio...
First, check if the ibiblio site is ok with your favorite browser. If the site is ok, maybe it's a problem of proxy configuration. Set your ANT_OPTS environment variable to configure your proxy if you have one. For instance:
set ANT_OPTS=-Dhttp.proxyHost=monproxy -Dhttp.proxyPort=3128

If it still doesn't work, maybe it's your dependency file which is not ok. Check if the module name you depend on is actually a name of directory under www.ibiblio.org/maven/. If this is the case, check if the jar with a name like [module]-[revision].jar is present under the jars directory of this module on ibiblio. For instance: www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar

If this is the case, check your ivy configuration to see if you actually use the ibiblio resolver.

Finally, you can check if the files were not downloaded but corrupted (Ivy has no md5 checking for the moment) by checking your lib directory and opening the jars if any with an unzip program.

If you still have problems post on the forum mentioning your OS, your version of ant, your version of ivy, your configuration file and your ivy file.
Ivy beginners questions

What if I do not want to put my library files in the lib directory ?
No problem, you just have to set an ant property:
<property name="ivy.lib.dir" value="pathtomylibdir"/>

What if I do not want the revision of the files I retrieve to appear in the file name ?
A typical question for people using an IDE like eclipse and often changing dependency revision: it's a bit boring to change your IDE project just to tell him to use comp-build2596.jar instead of comp-build2595.jar, when you have already changed your ivy file (and even if you haven't changed it, if you use the continuous integration feature !). No problem, you have a total control on the files retrieved using the pattern attribute in the retrieve task:
Here is the default pattern:
<ivy:retrieve pattern="${ivy.lib.dir}/[artifact]-[revision].[type]"/>
And here is one which do not suffix file name with dependency revision:
<ivy:retrieve pattern="${ivy.lib.dir}/[artifact].[type]"/>
And one which makes your lib directory seem like the ibiblio repository:
<ivy:retrieve pattern="${ivy.lib.dir}/[module]/[type]s/[artifact]-[revision].[type]"/>
Not too difficult, and really flexible, isn't it ? And check the retrieve task reference documentation to learn more about it...
What if I do not find the component I depend on in the maven ibiblio repository, or if i cannot access it ?
The maven ibiblio repository is interesting to use because it exists, but it have some limitations, which might make you consider using a different repository for retrieving your dependencies.
No problem, ivy proposes other way to resolve your dependencies. For the moment, here are the possibilities:

the maven ibiblio repository

a central file based repository (using OS file sharing mechanism)

any url based repository (http, ftp, ...)

any repository for which you are able to write a DependencyResolver

any combination of them

Note that the maven ibiblio repository and the url based repository have some limitations, particularly they cannot be used with the continuous integration feature of ivy.

Services
top
Development Environment Consulting and Services
As the author of Ivy, our company is able to propose its expertise in the development environment field.

Do you have troubles to manage the dependencies of your projects ? Do you often face problems when you have to deliver a product ? Did you ever spent hours, or even days, to align the dependencies of all of your components ? Did you ever faced a last minute bug due to a tardive integration of your components ?

A good development environment can help you solves these problems, have a better and cleaner delivery process, and make your developer happier !

You can find a resume about some problematics of development environment and the services we provide on this presentation.

Development Environment Consulting
The cheapest service is a remote review of your development environment, with a lot of advices and code examples (sample ant build files, sample ivy files) to make it cleaner and more effective.
Usually 1 to 2 days only are necessary.
Development Environment Booster Kit
We offer an in-house set up of a better development environment, reviewing your existing environment and setting up a better one with ant, ivy, enterprise repository with simple publishing process, and the ability for developers to use their own workspace components instead of enterprise one during development.
At the end of this setup, a fully working development environment will be ready to use in your company.
You will still have to migrate your projects to this new environment, following some simple steps.
Usually only 1 to 3 days in your offices are necessary.
Turnkey Option
You do not want to bother with the integration of your build files and process with the new fully working development environment ? You can ask us to migrate all your build stuff to the new environment, so that you just have to enjoy the power of clean dependency management and delivery process !
This option usually takes from 1 to 10 days, depending on the complexity of your existing builds and on the number of projects / components you use.
Continuous Integration Option
Have you ever heard of all the benefits of continuous integration ?
If you don't, have a look to Martin Fowler article on the subject. It may give you a good idea of why we strongly recommend setting up continuous integration for your projects.
With this option, we setup a fully working continuous integration environment (based upon cruise control and ivy), which takes the dependencies between your projects into account to know what should be built. With our setup, you can easily go back to any integration build, and promote it to a delivery if you want !
Moreover, this option usually takes only from 1 to 3 days.
Contact us
Do any of these services interest you ? Have you another idea for which we could help ?
Feel free to contact us: sales@jayasoft.org
Links
top
Links

They talk about Ivy
Xavier Hanin Weblog (maybe a bit biased ;-) )
Decision to use Ivy is a no-brainer
Cool Dependency Managment in Projects/Builds
Using Ivy in AppFuse
maven:uninstall
Ivy is everything Maven should have/could have been 2.5 years ago
Ivy Rocks!
Ant vs Maven and dependency management
how to manage dependencies in Ant
Dependency Management with Ant using Ivy
Maven vs Ant Reloaded
Ant Dependency Resolver
Ivy, Dependency Manager
RE: Ivy is everything Maven should be

Ivy in the news
1.0 Announce on The Servier Side
Entry in freshmeat.net

Documentation

Tutorial

Overview

Main features

Testimonials

Tools and plugins

Main benefits

Simplicity

Transitive dependencies management

Continuous integration ready

Simple example

1. Download and install

2. Describe your dependencies

3. Call ivy from your ant build file

About this site

Starting with ivy

The ivy.xml file

Running the project

What happened ?

Starting with ivy

The ivy.xml file

Running the project

What happened ?

purpose

project description

the project : chained-resolvers

the ivy configuration

the conf tag

the resolvers tag

walkthrough

step 1 : preparation

step 2 : clean directory tree

step 3 : run the project

Dual Resolver Tutorial

project description

the dual project

the ivy configuration

walkthrough

step 1 : preparation

step 2 : clean up

step 3 : run the project

purpose

the projects used

the project : standalone

the project : depending

the ivy configuration

the properties tag

the conf tag

the resolvers tag

the modules tag

walkthrough

step 1 : preparation

step 2 : clean directory tree

step 3 : publication of standalone project

step 4 : running the depending project

step 5 : new version of standalone project

step 6 : depending got the new version

Presentation

Terminology

Organisation

Module

Artifact

Revision

Configuration

Status

Main concepts

Dependency Resolver

Latest Strategy

Conflict Manager

Variables

Patterns

Installation

Ivy Configuration

Configuration file structure

Child elements

Attributes

Attributes

Attributes

Child elements

Child elements