Apache Ivy

From Bauman National Library
This page was last modified on 17 January 2019, at 14:27.
Apache Ivy
Ivy-lierre.png
Original author(s) Jayasoft
Developer(s) Apache Software Foundation
Initial release 2004
Repository {{#property:P1324}}
Development status Active
Written in Java
Platform Crossplatform
Type Dependency manager
License Apache License 2.0
Website ant.apache.org/ivy/

Apache Ivy is a dependency manager for Java projects, with support for transitive dependencies. It is an integrated utility in Apache Ant [1].

Review

Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies. It is characterized by the following:

  1. flexibility and configurability - Ivy is essentially process agnostic and is not tied to any methodology or structure. Instead it provides the necessary flexibility and configurability to be adapted to a broad range of dependency management and build processes.
  2. tight integration with Apache Ant - while available as a standalone tool, Ivy works particularly well with Apache Ant providing a number of powerful Ant tasks ranging from dependency resolution to dependency reporting and publication.

Ivy is open source and released under a very permissive Apache License. Ivy has a lot of powerful features, the most popular and useful being its flexibility, integration with Ant, and its strong transitive dependencies management engine.

The transitive dependencies management is a feature which lets you get dependencies of your dependencies, transitively. In order to address this general problem, Ivy needs to find metadata about your modules, usually in an Ivy file. To find the metadata and your dependencies' artifacts (usually jars), Ivy can be configured to use a lot of different repositories.

History

Jayasoft first created Ivy in September, 2004, with Xavier Hanin serving as the principal architect and developer of the project. Jayasoft moved hosting of Ivy (then at version 1.4.1) to Apache Incubator in October 2006. Since then, the project has undergone package renaming to reflect its association with the Apache Software Foundation. Package names prefixes of the form fr.jayasoft.ivy have become org.apache.ivy prefixes. Ivy graduated from the Apache Incubator in October, 2007. As of 2009 it functions as a sub-project of Apache Ant.

Features

  • Managing project dependencies. Clean dependency reports. Apache Ivy produces two primary report types: HTML reports and graph reports. HTML reports give a good understanding of what Apache Ivy did, and of a project's immediate dependencies. The graph reports provide a good overview of a project's transitive dependencies and conflicts.
  • Non intrusive. Apache Ivy is most commonly used to resolve dependencies and copy them to the lib directory of a project. After dependencies have been copied, a build no longer depends on Apache Ivy. Therefore, existing builds may easily be migrated to Apache Ivy using the lib directory pattern. Also, dependencies can be delivered with a project so that the build file need not depend on Apache Ivy.
  • Easily extensible. When Apache Ivy does not do what you want out of the box, you can often extend it to solve your problem. For instance, you can plug your own repository. But you can also define your own latest strategy and your own conflict manager.
  • Extrimely flexible. Apache Ivy comes with many default values that work out of the box, and most can be changed. For example, you can change the way Apache Ivy finds the latest dependency versions, you can change the conflict manager, you can choose if you want Apache Ivy to copy dependencies to your project libs or use them directly from the cache, etc.
  • XML-driven declaration of project dependencies and JAR repositories.
  • Automatic retrieval of transitive dependency definitions and resources.
  • Automatic integration to publicly available artifact repositories.
  • Resolution of dependency closures.
  • Configurable project state definitions, which allow for multiple dependency-set definitions.
  • Publishing of artifacts into a local enterprise repository.

Configuration of a module

Module configurations are described in the terminology page as a way to use or construct a module. Configurations being a central part of Ivy, they need more explanations as a concept. If the same module has different dependencies based on how it’s used, those distinct dependency-sets are called its configurations in Ivy.

Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server). Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those different ways to use or build a module are called module configurations in Ivy.

When you define a way to use or construct a module, you are able to define which artifacts are published by this module in this configuration, and you are also able to define which dependencies are needed in this configuration.

Moreover, because dependencies in Ivy are expressed on modules and not on artifacts, it is important to be able to define which configurations of the dependency are required in the configuration you define of your module. That’s what is called configuration mapping.

If you use only simple modules and do not want to worry about configurations, you don’t have to worry about them. They’re still there under the hood because Ivy can’t work without configurations. But most of the time if you declare nothing, Ivy assumes that the artifacts of your module are published in all configurations, and that all the dependencies' configurations are required in all configurations. And it works in simple cases. But whenever you want to separate things within a module, or get more control over things published and get better dependencies resolution, configurations will meet most of your needs.

Example of dependency configuration

This file describes the dependencies of the project on other libraries. Here is the sample [2]:

<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 be pretty easy to understand. First, the root element is ivy-module, with the version attribute telling Ivy which lowest version of Ivy this file is compatible with. Then there is an info tag, which provides information about the module for which we are defining dependencies. Here we define only the organization and module names. 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. In this example, 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.

Сomparison with Apache Maven

First, the most important difference is that they aren't at all the same kind of tools [3]. Apache Maven is a software project management and comprehension tool, whereas Apache Ivy is only a dependency management tool, highly integrated with Apache Ant, the popular build management tool. So maybe a more interesting comparison would compare Apache Ant+Ivy vs Apache Maven. But this goes beyond the scope of this page which concentrates on dependency management only.

Apache Ivy heavily relies on a unique concept called configuration. In Apache Ivy, a module configuration is a way to use or to see the module. For instance, you can have a test and runtime configuration in your module. But you can also have a mysql and an oracle configuration. Or an hibernate and a jdbc configuration. In each configuration you can declare what artifacts (jar, war, ...) are required. And in each configuration, you can declare your dependencies on other modules, and describe which configuration of the dependency you need. This is called configuration mapping, and it is a very flexible way to answer to a lot of problems we face very often in software development.

Apache Maven on its side has something called the scope. You can declare a dependency as being part of the test scope, or the buildtime scope. Then depending on this scope you will get the dependency artifact (only one artifact per module) with its dependencies depending on their scope. Scopes are predefined and you can't change that. No way to create an oracle scope. No way to indicate you need what has been declared to be needed in the runtime scope of your dependency in your compile one. Everything here is written in the marble.

Installation

For macOS we should install brew utility For that we should open the terminal and write down next commands:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

After brew installation type in these words:

brew install ant
brew install ivy

After this step we have ant and ivy programs installed(Ant should be installed for ivy's normal functionality. After .xml file configuration for project compilation we should go to its folder and run ivy command. For example download sources from here. Unpacking archive and then:

cd to src/example/(any folder)
ivy

Installation process on video:

References

  1. Apache Ivy Documentation // Apache Ivy [2007 - 2018] URL: http://ant.apache.org/ivy/history/2.5.0-rc1/index.html (Access date: 02.01.2019)
  2. Apache Ivy Quick Start // Apache Ivy [2007 - 2018] URL: http://ant.apache.org/ivy/history/2.5.0-rc1/tutorial/start.html (Access date: 02.01.2019)
  3. Apache Ivy comparison with Apache Maven // Apache Ivy [2007-2019] URL: http://ant.apache.org/ivy/m2comparison.html (Access date: 02.01.2019)