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 <a href="../terminology.html">here</a> and <a href="../ivyfile/configurations.html">here</a>. <h1>Introduction</h1> Source code is available in <tt>src/example/configurations/multi-projects</tt>. 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. <h1>The library project</h1> 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. <h2>The ivy.xml file</h2> <div class="ivy-file"> <code type="xml"> <ivy-module version="1.0"> <info organisation="org.apache" module="filter-framework"/> <configurations> <conf name="api" description="only provide filter framework API"/> <conf name="homemade-impl" extends="api" description="provide a home made implementation of our api"/> <conf name="cc-impl" extends="api" description="provide an implementation that use apache common collection framework"/> <conf name="test" extends="cc-impl" visibility="private" description="for testing our framework"/> </configurations> <publications> <artifact name="filter-api" type="jar" conf="api" ext="jar"/> <artifact name="filter-hmimpl" type="jar" conf="homemade-impl" ext="jar"/> <artifact name="filter-ccimpl" type="jar" conf="cc-impl" ext="jar"/> </publications> <dependencies> <dependency org="commons-collections" name="commons-collections" rev="3.1" conf="cc-impl->default"/> <dependency org="junit" name="junit" rev="3.8" conf="test->default"/> </dependencies> </ivy-module> </code> </div> <h2>Explanation</h2> As you can see, we defined 4 configurations, with 3 being public and 1 private. (the junit dependency for testing). The 2 implementation configurations, <b>homemade-impl</b> and <b>cc-impl</b> extend the <b>api</b> configuration so that all artifacts defined in <b>api</b> 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. <h2>See it in action</h2> The filter-framework project is built using Ant. Open a shell in the root directory of the project and type <tt>ant</tt>. <div class="shell"><pre> [<tutorial/log/configurations-lib.txt>] </pre></div> 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. (<tt>${home.dir}/.ivy2/local/org.apache/filter-framework/</tt>) At this point, we are ready to use our library. <h1>The application project</h1> Now that we have shipped (published) our fantastic filter library, we want to use it! The tutorial comes with a sample application called myapp. <h2>The <tt>ivy.xml</tt> file</h2> <div class="ivy-file"> <code type="xml"> <ivy-module version="1.0"> <info organisation="org.apache" module="myapp"/> <configurations> <conf name="build" visibility="private" description="compilation only need api jar" /> <conf name="noexternaljar" description="use only company jar" /> <conf name="withexternaljar" description="use company jar and third party jars" /> </configurations> <dependencies> <dependency org="org.apache" name="filter-framework" rev="latest.integration" conf="build->api; noexternaljar->homemade-impl; withexternaljar->cc-impl"/> </dependencies> </ivy-module> </code> </div> <h2>Explanation</h2> We create 3 configurations that define the different ways we want to use the application. The <b>build</b> 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 <a href="../ivyfile/configurations.html">here</a> <ol> <li><b>build->api</b> : here we tell Ivy that our <b>build</b> configuration depends on the <b>api</b> configuration of the dependency</li> <li><b>noexternaljar->homemade-impl</b> : here we tell Ivy that our <b>noexternaljar</b> configuration depends on the <b>homemade-impl</b> configuration of the dependency.</li> <li><b>withexternaljar->cc-impl</b> : here we tell Ivy that our <b>withexternaljar</b> configuration depends on the <b>cc-impl</b> configuration of the dependency</li> </ol> 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 <tt>build.xml</tt> file, we defined a 'resolve' target as follow: <code type="xml"> <target name="resolve" description="--> retreive dependencies with ivy"> <ivy:retrieve pattern="${ivy.lib.dir}/[conf]/[artifact].[ext]"/> </target> </code> When we call this target, Ivy will do a resolve using our <tt>ivy.xml</tt> 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: <div class="shell"><pre> Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib 01/24/2006 11:19 AM <REP> build 01/24/2006 11:19 AM <REP> noexternaljar 01/24/2006 11:19 AM <REP> withexternaljar 0 fichier(s) 0 octets Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib\build 01/24/2006 10:53 AM 1,174 filter-api.jar 1 fichier(s) 1,174 octets Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib\noexternaljar 01/24/2006 10:53 AM 1,174 filter-api.jar 01/24/2006 10:53 AM 1,030 filter-hmimpl.jar 2 fichier(s) 2,204 octets Repertoire de D:\ivy\src\example\configurations\multi-projects\myapp\lib\withexternaljar 01/24/2006 10:53 AM 559,366 commons-collections.jar 01/24/2006 10:53 AM 1,174 filter-api.jar 01/24/2006 10:53 AM 1,626 filter-ccimpl.jar 3 fichier(s) 562,166 octets </pre></div> As you can see, for each configuration we have now a set of jars. Let's try to launch our app. <h2>See it in action</h2> Use Ant to run the application. The default Ant target is <i>run-cc</i> and will launch the application using the Apache commons-collections implementation. <div class="shell"><pre> [<tutorial/log/configurations-runcc.txt>] </pre></div> Launching the application using the homemade implementation is also straightforward. type <tt>ant run-hm</tt> <div class="shell"><pre> [<tutorial/log/configurations-runhm.txt>]</pre></div> Nice! We got the same result, but we can see that the implementation classes are different. <h1>Conclusion</h1> <b>You should use configurations as often as possible.</b> 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.