This is a self-assessment activity to give you practice in working with the Ivy configuration manager. Feel free to share your problems, experiences, and choices in the Forum.

In a previous lab, you set up an Eclipse project with an associated Ant build.

We’ll use that as a starting point for this lab.

One of the sticking points in the previous lab came when we needed to supply the JUnit and Hamcrest libraries to the build process. Our solution at the time was to download those to some convenient directory and to hard-code that location into our build:

    <path id="test.compilation.path">
        <pathelement path="target/classes"/>
        <pathelement path="/home/zeil/src/junit4.jar"/>
        <pathelement path="/home/zeil/src/hamcrest-core.jar"/>
    </path>

There are problems with this approach.

• Our build file can’t be used by other team members unless they have download the same files and stored them at exactly the same place, which is pretty unlikely.

• Unless we are very conscientious about checking the download site for new releases, we run the long-term risk of getting left behind with outdated versions of our libraries.

In this lab, we’ll replace those hard-coded download locations with a more dynamic, shareable approach based on Ivy.

1. The first thing to do is to make sure that our Ant build can use Ivy. I use pretty much the same steps for doing this in every project, so I have found it useful to package them into a separate build file. Download that file and save it in the same directory as your build.xml file, naming it ivy.build.xml.

2. Now edit your build.xml file and

   • Add

     <import file="ivy.build.xml"/>
     

   before the first of the “<path” declarations.

   • Then change the test.compilation.path declaration by removing the path elements for JUnit and Hamcrest and instead letting Ivy supply a path to any Jar files that it downloads for your project:

     <path id="test.compilation.path">
        <pathelement path="target/classes"/>
        <path refid="ivy.classpath"/>
     </path>
     

     (Look inside ivy.build.xml to see where ivy.classpath comes from. It’s set up by a cachepath command near the end.)

   • The ivy.build.xml file sets up a series of Ant targets that will load and run Ivy. But those targets won’t be invoked if none of the “real” targets of our build depend on them, and currently none do. So edit the compile target and make it depend on the successful completion of the resolve-ivy target:

     <target name="compile" depends="resolve-ivy"
     

3. The changes in the prior step will allow Ivy to run. But we need to tell Ivy just what libraries we actually need for this project.

   Create a new file named ivy.xml (in the same directory as build.xml and, in there, indicate that we need JUnit:

       <ivy-module version="2.0">
         <info organisation="edu.odu.cs" module="myProject" />
         <dependencies defaultconfmapping="*->default">
          <dependency org="junit" name="junit" 
            rev="4.11" />
         </dependencies>
       </ivy-module>
   

   Feel free to change the “info” to something more appropriate.

   This is a very minimal ivy.xml. In particular, there’s no real use of “configurations”, which are a useful but confusing tool for managing different views of the project (e.g., differentiating between different sets of 3rd-party libraries that are needed at different stages of the build).

   Note that we tell Ivy that we need JUnit but not Hamcrest. That’s because the only reason that we need Hamcrest is because JUnit needs it, and Ivy manages those kind of indirect dependencies for us.

4. Finally, we need to tell Ivy where to look for all these wonderful libraries that we want to download. that is done in an ivysettings.xml file. This tends to be something that is a fixed setup for all projects at a given company. This file is often not included in project source code for that reason, but is assumed to reside in the programmer’s home directory or in a shared locations accessible to the entire development team.

   We, however, are going to put it right into the same directory with our build file and other Ivy files. So download this file and store it in that same project directory.

5. Now run your Ant build.xml from inside Eclipse (or from the command line). Run it first with the target “clean” to get rid of the compilation results form the last lab.

   Then run it again with the default target (“build”). You should see some initial messages about fetching Ivy, then locating and fetching the JUnit and Hamcrest jars, before the rest of your build proceeds as normal.

4 Where is Everything?

1. Right-click on your Project name and select “Refresh”. You sill see that you have a new folder named “ivy” and, in there, and ivy.jar file. That’s the actual Ivy system support. If you delete this, it will be reconstructed next time you run your Ant build.

2. In your operating system, look at ~/.ivy2 if you are on a Linux or OS/X machine, or %HOME%/.ivy2 if you are on Windows. (%HOME% is generally C:\Users\_yourLoginName_ on a typical Windows system.)

   You should see local and cache directories. If you poke around inside cache, you should be able to find the jar files that Ivy has downloaded on your behalf.

   On occasion, you might find it useful to clear out this cache (e.g, if it’s holding a lot of libraries for older projects that you are no longer working on). It’s reasonably safe to do so, as Ivy will just re-download the libraries that you do need when you rebuild your current projects.

© 2015-2016, Old Dominion Univ.