Ivy 2.0: Released As An Apache Project

Posted by Alexander Olaru on Jan 16, 2008

Sections

Process & Practices,

Development,

Operations & Infrastructure

Topics

Java ,

Build systems

Tags

Maven ,

Ivy

Ivy, a tool for managing (recording, tracking, resolving and reporting) project dependencies which provides tight integration with Apache Ant, has released its 2.0 beta version. This is the first release as an Apache project, it brings enhanced compatibility with Maven 2 repositories, improved concurrency support and a few other significant changes. According to the release notes Ivy is characterized by:

• flexibility and configurability - it is process agnostic and not tied to any methodology or structure
• tight integration with Ant - it provides various Ant tasks ranging from dependency resolution to dependency reporting and publication, while available as a standalone tool as well.

Along with numerous bug fixes and updates to the tutorials to work with version 2.0, other major changes as part of this release are as follows:

• Configuration replaced by settings - to eliminate some confusion, settings (used to customize Ivy) are separated from configuration (used for module configurations).
• Review of settings loading - the deprecated configure task is replaced by a settings data type which allows the usage of several settings in one Ant build script.
• ivyrep no longer the default public resolver - it has been replaced by ibiblio Maven 2 repository.
• Relative path resolution - where relative paths were used for configuration file inclusion, the dependency resolution might be affected, as path resolution in 2.0, is done relative to the Ivy file in which the configurations are included vs. the current directory.

Ivy 2.0 is compatible with prior releases as long as custom plugins are not being used. As the prior versions have been released as Jayasoft projects, the new 2.0 version brings with it a change in package names, from fr.jayasoft.Ivy to org.apache.ivy.

Although Ivy has increased its integration with Maven 2 repositories, the project leads are very specific about the main differences between the two products and how Ivy can provide a viable alternative to the dependency management features present in Maven 2. Below are a few highlights:

Often compared side by side, Maven 2 and Ivy are actually not the same type of tools. While Ivy offers only dependency management capabilities, Maven 2 is a software project management and comprehension tool and can manage build, reporting and documentation as well as dependencies from a central piece of information. Ant + Ivy 2.0 might be a more suitable comparison to Maven 2.

Conflict management - the ability to deal with conflicts when dealing with transitive dependencies - is handled differently by the two tools. Ivy allows for customization of conflict managers and rules by modules while Maven 2's conflict management is based on the nearest definition (i.e. a module depending on foo 1.0 leads to none of the module's dependencies being able to use foo 1.1).

Configuration of dependencies in Maven 2 is handled through a concept called scope. A dependency in Maven 2 is limited to being defined as part of either a test or a build time scope. Ivy provides more customization options through the ability to create multiple configuration mappings which tie each configuration (a declaration of the needed build artifacts) to the dependencies on other modules.

The Ivy documentation is also presented in the comparison FAQ as being more extensive, including a large number of examples and tutorials, compared to Maven 2's limited documentation related to dependency management. For enterprises that can not use public repositories and have large investments in Ant-based build systems, Ivy's support for the creation of enterprise repositories and tight integration with Ant are other features that make Ivy a viable dependency management alternative to Maven 2.

1. Back to top

   project dependencies? we don't need no stinking tools for that!

   by Rusty Wright

   So, ignoring my inflamatory subject, here's my question: I use subversion for my revision control system, and with it I check in all of my libraries (jar files). I can go to another machine, check out my project, and compile.
   
   In that kind of a scenario, how would something like Ivy or Maven help me?

   Reply

2. Back to top

   Re: project dependencies? we don't need no stinking tools for that!

   by joris wijlens

   What i like about a dependency manager is that in combination with a plugin it synchronizes my Eclipse classpath with the one I have in ant/maven.
   
   One can have reporting about project dependencies.
   
   It is easier to initially gather dependencies for a project.
   
   It is easier to try out different versions of a dependency and back out again.
   
   It is easier to update a depending project with latest snapshots if you have multiple artifacts.

   Reply

3. Back to top

   Re: project dependencies? we don't need no stinking tools for that!

   by Ronald Miura

   I think this kind of dependency management doesn't bring that many benefits to most projects, but is a lifesaver when you have: 1) to manage the development of internal frameworks/libraries, that other internal projects depend on; 2) you have a system with many (interdependent) modules.
   
   If what you're doing will be used (as a library) for third-parties, you will want some form of dependency management tool.
   
   But if all you need is a bunch of jars from some stable opensource libraries that will be used only in your project, it doesn't buy you much, indeed.

   Reply

4. Back to top

   Re: project dependencies? we don't need no stinking tools for that!

   by Danno Ferrin

   ... In that kind of a scenario, how would something like Ivy or Maven help me?

   
   
   Likely not suitable for Ivy: I, Me, Mine. As in "I have a project that uses my library."
   
   Possibly suitable for Ivy: We, Us, Our. As in "we have a project in multiple modules."
   
   Definitely suitable for Ivy: You, Them, Theirs. As in "Project-Foo uses their library, and you need to get the code to build it."

   Reply

5. Back to top

   Re: project dependencies? we don't need no stinking tools for that!

   by Tom Halliley

   Suppose you want to manage libraries across many applications, as in a corporate environment? Rather than managing specific libraries with each application, refer to those libraries in Ivy repositories. In our environment, we wish to have architectural approval of libraries and versions thereof across projects and to ensure compatibility in our test and production environments. Managing this per application can cause conflicts later when deploying multiple applications into the same J2EE container.

   Reply

• Older >