Apache™ > Apache Ant™ > Apache Ivy™ > Documentation (2.4.0) > Tutorials > Using Ivy Module Configurations

Using Ivy Module Configurations

This tutorial introduces the use of module configurations in ivy files. Ivy module configurations are indeed a very important concept. Someone even told me one day that using Ivy without using configurations is like eating a good cheese without touching the glass of Chateau Margaux 1976 you have just poured :-)

More seriously, configurations in Ivy can be better understood as views on your module, and you will see how they can be used effectively here.

Reference documentation on configurations can be found here and here.

Introduction

Source code is available in src/example/configurations/multi-projects.
We have two projects :
- filter-framework is a library that defines an api to filter String arrays and two implementations of this api.
- myapp is a very small app that uses filter-framework.

The filter-framework library project produces 3 artifacts:
- the api jar,
- an implementation jar with no external dependencies,
- a second implementation jar that needs commons-collections to perform.

The application only needs the api jar to compile and can use either of the two implementations at runtime.

The library project

The first project we'll look at in this tutorial is filter-framework. In order to have a fine-grained artifacts publication definition, we defined several configurations, each which maps to a set of artifacts that other projects can make use of.

The ivy.xml file

Explanation

As you can see, we defined 4 configurations, with 3 being public and 1 private. (the junit dependency for testing).
The 2 implementation configurations, homemade-impl and cc-impl extend the api configuration so that all artifacts defined in api will also be part of the extending configuration.

In the publications tag, we defined the artifacts we produce (jars in this case) and we assign them to a configuration. When others use our library they will have a flexible way to ask for what they need.

See it in action

The filter-framework project is built using Ant. Open a shell in the root directory of the project and type ant. The Ant default target is publish. This target uses Ivy to publish our library binaries to a local repository. Since we do not specify any repository path, the default one is used. (${home.dir}/.ivy2/local/org.apache/filter-framework/) At this point, we are ready to use our library.

The application project

Now that we have shipped (published) our fantastic filter library, we want to use it! The tutorial comes with a sample application called myapp.

The ivy.xml file

Explanation

We create 3 configurations that define the different ways we want to use the application. The build configuration defines the compile-time dependencies, and thus only needs the api conf from the filter-framework project. The other two configurations define runtime dependencies. One will only use our "home-made" jar, and the other will use an external jar.

We also defined a dependency on our previously built library. In this dependency, we use configuration mappings to match ours with the dependency's configurations. You can find more information about configuration mapping here

1. build->api : here we tell Ivy that our build configuration depends on the api configuration of the dependency
2. noexternaljar->homemade-impl : here we tell Ivy that our noexternaljar configuration depends on the homemade-impl configuration of the dependency.
3. withexternaljar->cc-impl : here we tell Ivy that our withexternaljar configuration depends on the cc-impl configuration of the dependency

Note that we never declare any of the dependency's artifacts we need in each configuration: it's the dependency module's ivy file which declares the published artifacts and which should be used in each configuration.

In the Ant build.xml file, we defined a 'resolve' target as follow:

<target name="resolve" description="--> retreive dependencies with ivy">
    <ivy:retrieve pattern="${ivy.lib.dir}/[conf]/[artifact].[ext]"/>
</target>    

When we call this target, Ivy will do a resolve using our ivy.xml file in the root folder and then retrieve all the artifacts. The artifacts retrieved are kept in separate folders according to the configurations they belong to. Here is how your lib directory should look after a call to this target: As you can see, for each configuration we have now a set of jars.

Let's try to launch our app.

See it in action

Use Ant to run the application. The default Ant target is run-cc and will launch the application using the Apache commons-collections implementation. Launching the application using the homemade implementation is also straightforward.
type ant run-hm Nice! We got the same result, but we can see that the implementation classes are different.

Conclusion

You should use configurations as often as possible. Configurations are a very important concept in Ivy. They allow you to group artifacts and give the group a meaning. When you write ivy files for projects that are intended for use by others, use configurations to allow people to get only what they need, without having to specify them one by one in their own dependency list.