Quick Start


In this tutorial, you will see one of the simplest ways to use Ivy. With no specific settings, Ivy uses the maven 2 repository to resolve the dependencies you declare in an Ivy file. Let's have a look at the content of the files involved.

You'll find this tutorial's sources in the ivy distribution in the src/example/hello-ivy directory.

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="2.0">
    <info organisation="org.apache" module="hello-ivy"/>
    <dependencies>
        <dependency org="commons-lang" name="commons-lang" rev="2.0"/>
        <dependency org="commons-cli" name="commons-cli" rev="1.0"/>
    </dependencies>
</ivy-module>
The format of this file should pretty easy to understand, but let's give some details about what is declared here. First, the root element ivy-module, with the version attribute used to tell Ivy which version of Ivy this file uses.

Then there is an info tag, which is used to give information about the module for which we are defining dependencies. Here we define only the organization and module name. You are free to choose whatever you want for them, but we recommend avoiding spaces for both.

Finally, the dependencies section lets you define dependencies. Here this module depends on two libraries: commons-lang and commons-cli. As you can see, we use the org and name attributes to define the organization and module name of the dependencies we need. The rev attribute is used to specify the version of the module you depend on.

To know what to put in these attributes, you need to know the exact information for the libraries you depend on. Ivy uses the maven 2 repository by default, so we recommend you use mvnrepository.com to look for the module you want. Once you find it, you will have the details on how to declare the dependency in a maven POM. For instance: 
<dependency>
    <groupId>commons-lang</groupId>
    <artifactId>commons-lang</artifactId>
    <version>2.0</version>
</dependency>
To convert this into an Ivy dependency declaration, all you have to do is use the groupId as organization, the artifactId as module name, and the version as revision. That's what we did for the dependencies in this tutorial, that is commons-lang and commons-cli. Note that having commons-lang and commons-cli as organization is not the best example of what the organization should be. It would be better to use org.apache, org.apache.commons or org.apache.commons.lang. However, this is how these modules are identified in the maven 2 repository, so the simplest way to get them is to use the details as is (you will see in Building a repository that you can use namespaces to redefine these names if you want something cleaner).

If you want more details on what you can do in Ivy files, you can have a look at the Ivy files reference documentation.

The build.xml file

The corresponding build file contains a set of targets, allowing you to resolve dependencies declared in the Ivy file, to compile and run the sample code, produce a report of dependency resolution, and clean the cache or the project.
You can use the standard "ant -p" to get the list of available targets. Feel free to have a look at the whole file, but here is the part relevant to dependency resolution: 
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="hello-ivy" default="run">
    
    ...
    
    <!-- ================================= 
          target: resolve              
         ================================= -->
    <target name="resolve" description="--> retrieve dependencies with ivy">
        <ivy:retrieve />
    </target>
</project>
As you can see, it's very easy to call Ivy to resolve and retrieve dependencies: all you need if Ivy is properly installed is to define an XML namespace in your Ant file (xmlns:ivy="antlib:org.apache.ivy.ant"). Then all the Ivy ant tasks will be available in this namespace.

Here we use only one task: the retrieve task. With no attributes, it will use default settings and look for a file named ivy.xml for the dependency definitions. That's exactly what we want, so we need nothing more than that.

Note that in this case we define a resolve target and call the retrieve task. This may sound confusing, actually the retrieve task performs a resolve (which resolves dependencies and downloads them to a cache) followed by a retrieve (a copy of those file to a local project directory). Check the How does it work ? page for details about that.

Running the project

OK, now that we have seen the files involved, let's run the sample to see what happens. Open a shell (or command line) window, and enter the hello-ivy example directory.
Then, at the command prompt, run ant:

What happened ?

Without any settings, Ivy retrieves files from the maven 2 repository. That's what happened here.
The resolve task has found the commons-lang and commons-cli modules in the maven 2 repository, identified that commons-cli depends on commons-logging and so resolved it as a transitive dependency. Then Ivy has downloaded all corresponding artifacts in its cache (by default in your user home, in a .ivy2/cache directory). Finally, the retrieve task copies the resolved jars from the ivy cache to the default library directory of the project: the lib dir (you can change this easily by setting the pattern attribute on the retrieve task).

You might say that the task took a long time just to write out a "Hello Ivy!" message. But remember that a lot of time was spent downloading the required files from the web. Let's try to run it again:
Great! The cache was used, so no download was needed and the build was instantaneous.

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.

As you can see, using Ivy to resolve dependencies stored in the maven 2 repository is extremely easy. Now you can go on with the next tutorials to learn more about how to use module configurations which is a very powerful Ivy specific feature. Other tutorials are also available where you will learn how to use Ivy settings to leverage a possibly complex enterprise repository. It may also be a good time to start reading the reference documentation, and especially the introduction material which gives a good overview of Ivy. The best practices page is also a must read to start thinking about how to use Ant+Ivy to build a clean and robust build system.