Apache Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies, characterized by flexibility, configurability, and tight integration with Apache Ant.

You can download this release at https://ant.apache.org/ivy/download.cgi

Issues should either be discussed in the Ivy user mailing list or reported at https://issues.apache.org/jira/browse/IVY

More information about the project can be found on the website https://ant.apache.org/ivy/

Key features of this 2.5.0 release are:

For details about the following changes, check our JIRA install at https://issues.apache.org/jira/browse/IVY

List of changes since Ivy 2.4.0:

Here is the list of people who have contributed source code and documentation up to this release. Many thanks to all of them, and also to the whole IvyDE community contributing ideas and feedback, and promoting the use of Apache Ivy !

Committers:

Contributors:

If you have any trouble, check our FAQ.

OK, you’ve just seen how easy it is to take your first step with Ivy. Go ahead with the other tutorials, but before you do, make sure you have properly installed Ivy and downloaded the tutorials sources (included in all Ivy distributions, in the src/example directory).

The following tutorials are available:

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

The format of this file should be pretty easy to understand, but let’s discuss some details about what is declared here. 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.

To know what to put in these attributes, you need to know the exact information for the libraries you depend on. Ivy uses the Maven 2 central repository by default, so we recommend you use mvnrepository.com to look for the module you want. Once you find it, you will have the details of that module in the pom.xml file of that module. For instance:

To convert this into an Ivy dependency declaration, all you have to do is use the groupId as organization, the artifactId as module name, and the version as revision. That’s what we did for the dependencies in this tutorial, that is commons-lang and commons-cli. Note that having commons-lang and commons-cli as organization is not the best example of what the organization should be. It would be better to use org.apache, org.apache.commons or org.apache.commons.lang. However, this is how these specific modules were identified in the Maven 2 repository, so the simplest way to get them is to use the details as is (you will see in Building a repository that you can use namespaces to redefine these names if you want something cleaner).

If you want more details on what you can do in Ivy files, you can have a look at the Ivy files reference documentation.

The corresponding build file contains a set of targets, allowing you to resolve dependencies declared in the Ivy file, to compile and run the sample code, produce a report of dependency resolution, and clean the cache or the project. You can use the standard ant -p command to get the list of available targets. Feel free to have a look at the whole file, but here is the part relevant to dependency resolution:

As you can see, it’s very easy to call Ivy to resolve and retrieve dependencies: all you need if Ivy is properly installed is to define an XML namespace in your Ant file (xmlns:ivy="antlib:org.apache.ivy.ant"). Then all the Ivy Ant tasks will be available in this namespace.

Here we use only one task: the retrieve task. With no attributes, it will use default settings and look for a file named ivy.xml for the dependency definitions. That’s exactly what we want, so we need nothing more than that.

Note that in this case we define a resolve target and call the retrieve task. This may sound confusing, actually the retrieve task performs a resolve (which resolves dependencies and downloads them to a cache) followed by a retrieve (a copy of those file to a local project directory). Check the How does it work ? page for details about that.

OK, now that we have seen the files involved, let’s run the sample to see what happens. Open a shell (or command line) window, and go into the hello-ivy example directory. Then, at the command prompt, run ant:

Without any settings, Ivy retrieves files from the Maven 2 repository. That’s what happened here. The resolve task has found the commons-lang and commons-cli modules in the Maven 2 central repository, identified that commons-cli depends on commons-logging and so resolved it as a transitive dependency. Then Ivy has downloaded all corresponding artifacts in its cache (by default in your user home, in a .ivy2/cache directory). Finally, the retrieve task copies the resolved jars from the Ivy cache to the default library directory of the project: the lib dir (you can change this easily by setting the pattern attribute on the retrieve task).

You might say that the task took a long time just to write out a "Hello Ivy!" message. But remember that a lot of time was spent downloading the required files from the web. Let’s try to run it again:

Great! The cache was used, so no download was needed and the build was instantaneous.

And now, if you want to generate a report detailing all the dependencies of your module, you can call the report target, and check the generated file in the build directory. You should obtain something looking like this.

As you can see, using Ivy to resolve dependencies stored in the Maven 2 repository is extremely easy. Now you can go on with the other tutorials to learn more about how to use module configurations which is a very powerful Ivy specific feature. More tutorials are also available where you will learn how to use Ivy settings to leverage a possibly complex enterprise repository. It may also be a good time to start reading the reference documentation, and especially the introduction material which gives a good overview of Ivy. The best practices page is also a must read to start thinking about how to use Ant+Ivy to build a clean and robust build system.

The default settings include 3 types of repositories:

Note that if you work alone, the distinction between a local and shared repository is not very important, but there are some things you should know to distinguish them.

Now let’s describe each of these repository concepts in more detail. We will describe how they are set up physically later.

Now that we have seen the objective of each of the three repositories, let’s see how they are set up and how to configure them to fit your needs.

First, several repositories use the same root in your filesystem. Referenced as ${ivy.default.ivy.user.dir}, this is by default the directory .ivy2 in your user home.

Note that several things can be done by setting Ivy variables. To set them without defining your own ivysettings.xml file, you can:

For example:

Next we will show you how to override default values for the different kinds of repositories. Note that you can find what the default values are below in the details of the default settings.

OK, so we have seen how to easily change the settings of the three main repositories. But what if my shared repository is on a web server? What if you don’t want to use Maven 2 repository as the public repository? What if …​

No problem, Ivy is very flexible and can be configured with specific settings to match your needs and environment. But before considering writing your own settings from scratch, we suggest reading the following where you will learn how to leverage a part of the default settings and adjust the rest.

But before explaining how, you will need to have a quick overview of how Ivy is configured by default.

By default, Ivy is configured using an ivysettings.xml which is packaged in the Ivy jar. Here is this settings file:

OK, so not much info here, except a lot of inclusions. These inclusions have been done on purpose so that you can easily change only one part of the Ivy settings and easily benefit from the rest. For example, if you want to define your own public resolver, you will just have to configure Ivy with the settings like the following:

Note that only the ivysettings-public.xml inclusion has changed to include a homemade public resolver. Note also that this can be used like that thanks to the fact that ${ivy.default.settings.dir} is a variable which is always set to the place where Ivy’s default settings files are (i.e. packaged in the jar).

To finish this example, you have to write your own Ivy settings file (that you will make available at http://myserver/ivy/myivysettings-public.xml in this example) for defining your own public resolver. For instance, the contents of such a file could be:

Now the last thing you will need in order to properly take advantage of the default settings is the content of each included Ivy settings file:

There you go, you should have enough clues to configure Ivy the way you want. Check the settings documentation to see if what you want to do is possible, and go ahead!

This very simple example helps us see how to set up two resolvers in a chain. The chain resolver’s reference documentation is available for those who would like to know all the features offered by this resolver.

Below are a few more interesting things worth knowing about chain resolvers. After reading them, go ahead and try tweaking this example using your new wealth of knowledge!

In some cases, your module descriptions (i.e. Ivy files, Maven POMs) are located separately from the module artifacts (i.e. jars). So what can you do about it?

Use a Dual resolver! And this tutorial will show you how.

Let’s have a look at the src/example/dual directory in your Ivy distribution. It contains a build file and 3 directories:

This tutorial will show you how to use Ivy when one of your projects depends on another.

For our example, we will have two projects, depender and dependee, where the depender project uses/requires the dependee project. This example will help illustrate two things about Ivy:

The Ivy settings are defined in two files located in the settings directory:

Let’s have a look at the ivysettings.xml file:

The file contains four main tags: properties, settings, resolvers and modules.

In the previous tutorial, you saw how to deal with dependencies between two simple projects.

This tutorial will guide you through the use of Ivy in a more complex environment. All of the code for this tutorial is available in the src/example/multi-project directory of the Ivy distribution.

Here is a 10000 ft overview of the projects involved in this tutorial:

For sure this is not aimed to demonstrate how to develop a complex app or give indication of advanced algorithm :-)

But this gives a simple understanding of how Ant+Ivy can be used to develop an application divided in multiple modules.

Now, here is how these modules relate to each other:

click to enlarge

Modules in yellow are the modules described in this tutorial, and modules in blue are external dependencies (we will see how to generate this graph later in this tutorial).

As you can see, we have here a pretty interesting set of modules with dependencies between each other, each depending on the latest version of the others.

The sources for this tutorial can be found in src/example/multi-project in the Ivy distribution. In this directory, you will find the following files:

Note that this example doesn’t demonstrate many good practices for software development in general, in particular you won’t find any unit test in these samples, even if we think unit testing is very important. But this isn’t the aim of this tutorial.

Now that you are a bit more familiar with the structure, let’s have a look at the most important part of this example: the common build file. Indeed, as you have seen, all the module’s build files only import the common build file, and define their dependencies in their Ivy files (which you should begin to be familiar with).

So, here are some aspects of this common build file:

You can play with this tutorial by using regular Ant commands. Begin in the base directory of the tutorial (src/example/multi-project), and run ant -p:

This gives you an idea of what you can do here. To make sure you have at least one version of all your modules published in your repository (required to build modules having dependencies on the others), you can run ant publish-all (example log here).

You will see that Ivy calls the publish target on all the modules, following the order of the dependencies, so that a dependee is always built and published before its depender. Feel free to make changes in the source code of a module (changing a method name, for instance) and in the module using the method, then call publish-all to see how the change in the dependee is compiled first, published, and then available to the depender which can compile successfully.

Then you can go in one of the example project directories (like projects/find, for instance), and run ant -p:

You can see the targets available, thanks to the import of the common.xml build file. Play with the project by calling resolve, and publish, and see what happens when you do the same in other projects. An interesting thing to do, for instance, is to change the dependencies of a project. If the module version now depends on a new commons library, you will see that all other projects depending on that version will get this library as part of their transitive dependencies once the new revision of the version project is published. Very easy! And if a project introduces a change with which the depender isn’t compatible yet, you can easily change the dependency in the depender to move from latest.integration to a fixed version with which the depender is compatible (probably the latest before the change). Keeping your modules under control is now very easy!

By now, you should be pretty familiar with multi-project development with Ivy. We hope you will appreciate its power and flexibility! And these tutorials are only the beginning of your journey with Ivy, browse the reference documentation to learn more about the features, subscribe to the mailing lists to share your experience and ask questions with the community, browse the source code, open Jira issues, submit patches, join in and help make Ivy the best of dependency management tools!

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.

Source code is available in src/example/configurations/multi-projects. We have two projects:

The filter-framework library project produces 3 artifacts:

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

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

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

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.

The install Ant task lets you copy a module or a set of modules from one repository to another. This is very useful to build and maintain an enterprise or team repository. If you don’t want to give access to the public Maven 2 repository to the developers on your team (to keep control over which modules are in use in your company or your team, for instance), it can sometimes become tiresome to answer the developers request to add new modules or new versions by hand.

Fortunately the install task is here to help: you can use specific settings for your repository maintenance build which will be used to maintain your target enterprise repository. These settings will point to another repository (for instance, the Maven 2 public repository) so that you will just have to ask Ivy to install the modules you want with a simple command line.

To demonstrate this, we will first use a basic Ivy settings file to show how it works, and then we will use the advanced namespaces features to demonstrate how to deal with naming mismatches between the source and target repository.

The project that we will use is pretty simple. It is composed of an Ant build file, and two Ivy settings files.

Here are the public targets that we will use:

This project is accessible in the src/example/build-a-ivy-repository

Next steps:
Basic repository copy
Using namespaces

In this first step, we use the install Ant task to install modules from the Maven 2 repository to a file system based repository. We first install a module by itself, excluding dependencies, then again with its dependencies.

The Ivy settings file that we will use is very simple here. It defines two resolvers, libraries and my-repository. The first one is used as the source, the second one as the destination. In a typical setup, the second one would be configured using an include that included an existing settings file used by the development team.

Let’s have a look at the maven2 target.

Pretty simple, we call the ivy:install task with the settings we have loaded using ivy:settings as usual. We then set the source and destination repositories using the from and to attributes. We used Ant properties for these values here, which helps ease the maintenance of the script, but it’s basically the name of our resolvers: 'libraries' for the source and 'my-repository' for the destination.

Here is the Ant call output :

The trace tells us that the module definition was found using the "libraries" resolver and that the corresponding artifact was downloaded from the Maven 2 repository. Then both were published to the filesystem repository (my-repository).

Let’s have a look at our repository :

We can see that we now have the commons-lang module version 1.0 in our repository, with a generated ivy.xml file, its jar, and all the md5 and sha1 checksums for future consistency checks when developers use this repository to resolve modules.

Now let’s say that we want to be sure all the dependencies of the module we install are available in our repository after the installation. We could either install without dependencies in a staging repository and check the missing dependencies (more control), or use transitive dependency management and ask Ivy to install everything for us (much simpler).

The maven2-deps target is very similar to the one described above, except that we explicitly ask for transitive installation.

If you call this target, you will see that Ivy installs not only the hibernate module but also its dependencies:

As you can see the installation has failed, and if you look at the log you will see that there are missing artifacts in the source repository. This means that you will need to download those artifacts manually, and copy them to your destination repository to complete the installation. Fortunately Ivy uses a best effort algorithm during install, so that everything gets installed except the missing artifacts. (Note: these missing artifacts are not in the public Maven repository due to licensing issues.)

You may also have noticed that Ivy installed 2 different revisions of commons-logging (1.0.2, 1.0.4). This is due to the fact that we used the "no conflict" conflict manager in the Ivy settings file.

We do not want to evict any modules because we are building our own repository. Indeed, if we get both commons-logging 1.0.2 and 1.0.4, it’s because some modules among the transitive dependencies of hibernate depend on 1.0.2 and others on 1.0.4. If we got only 1.0.4, the module depending on 1.0.2 would be inconsistent in your own repository (depending on a version you did not install). Thus developers using this module directly would run into a problem.

If you now have a closer look at your repository, you will probably notice that it isn’t an exact replica of the original one. Let’s have a look at the directory of one module:

As you can see there is no POM here (POM is the module metadata format used by Maven 2, available in the Maven 2 repository). Instead you can see there’s an Ivy file, which is actually the original Hibernate POM converted into an Ivy file. So now you have a true Ivy repository with Ivy files, where you can use the full power of Ivy if you want to adjust the module metadata (module configurations, fine grained exclusions and transitivity control, per module conflict manager, …​).

OK, enough for this simple repository installation, the next tutorial will show how you can deal with more complex cases where your source and destination repositories do not follow the same naming conventions.

Now that you have seen how simple it is to create your own repository from an existing one, you may wonder how you can handle more complex cases, like when the source and destination repositories don’t follow the same naming conventions.

In this section, you will learn how to build a professional repository. What is a professional repository? Our vision is to say that a good quality repository must follow clear rules about project naming and must offer correct, usable configurations and verified project descriptors. In order to achieve those goals, we believe that you have to build your own repository. We have seen in the previous example, that we could use some public repositories to begin building our own repository. Nevertheless, the result is not always the expected one, especially concerning the naming rules used.

This problem is pretty normal when you have an existing repository, and want to benefit from large public repositories which do not follow the same naming conventions. It also shows up because many public repositories do not use a consistent naming scheme. For example, why don’t all the Apache Commons modules use the org.apache.commons organization? Well…​ for historical reasons. But if you set up your own repository, you may not want to suffer from the mistakes of history.

Fortunately, Ivy has a very powerful answer to this problem: namespaces.

If you look at the repository built with the previous tutorial, you will see exactly what we were talking about: all Apache Commons modules use their own name as their organization.

So let’s see what Ivy can do using namespaces (we will dig into details later):

Now if we look at our repository, it seems to look fine.

We can even have a look at the commons-lang Ivy file in our repository:

Alright, we see that the organisation is now 'apache'. But where did Ivy pick this up?

If you have successfully followed and understood all the tutorials, you still might need to get a better picture of how to use Ivy in the real world.

Here are some links which might be interesting:

SAnt is an experimental build system based on Ant and Ivy. It can be interesting to use "as is", or to get insight on an interesting approach to manage your builds.

The Spring Modules project build system is based on Ant and Ivy, and it’s really interesting to have a look at how a modularized project can take advantage of advanced Ant and Ivy features to make the build simpler.

The Webwork project (which became Struts Action framework) uses Ant+Ivy for their build, and thus makes their framework very easy to use in an Ant+Ivy build system. They have a page documenting how to use Ivy with their framework, which can be an interesting reading, even if you don’t plan to use Webwork.

Johan Stuyts, the author of SAnt, also contributed a nice article on his view of how to use Ivy on a multi-module environment.

Apache Ivy - Beginners Guide is a step by step guide to assist beginners in understanding basic concepts/tasks and use them straight away in their projects either through Ant build or in Eclipse IDE.

Welcome to the Ivy reference documentation!

If you don’t know Ivy at all, take a look at its features, the faq and the tutorials before digging into this reference documentation.

This documentation is broken into several parts:

Unresolved directive in book.adoc - include::../asciidoc/intro.adoc[]

Here are some terms used in Ivy, with their definitions in Ivy:

The following illustration shows all the key terminology in one diagram:

An organisation is either a company, an individual, or simply any group of people that produces software. In principle, Ivy handles only a single level of organisation, meaning that they have a flat namespace in Ivy module descriptors. So, with Ivy descriptors, you can only describe a tree-like organisation structure, if you use a hierarchical naming convention. The organisation name is used for keeping together software produced by the same team, just to help locate their published works.

Often organisations will use their inverted domain name as their organisation name in Ivy, since domain names by definition are unique. A company whose domain name is www.example.com might want to use com.example, or if they had multiple teams, all their organisation names could begin with com.example (e.g. com.example.rd, com.example.infra, com.example.services). The organisation name does neither really have to be an inverted domain name, nor even globally unique, but unique naming is highly recommended. Widely recognized trademark or trade name owners may choose to use their brand name instead.

Examples: org.apache, ibm, jayasoft

Note that the Ivy organisation is very similar to Maven POM groupId.

A module is a self-contained, reusable unit of software that, as a whole unit, follows a revision control scheme.

Ivy is only concerned about the module deliverables known as artifacts, and the module descriptor that declares them. These deliverables, for each revision of the module, are managed in repositories. In other words, to Ivy, a module is a chain of revisions each comprising a descriptor and one or more artifacts.

Examples: hibernate-entitymanager, ant

An artifact is a single file ready for delivery with the publication of a module revision, as a product of development.

Compressed package formats are often preferred because they are easier to manage, transfer and store. For the same reasons, only one or a few artifacts per module are commonly used. However, artifacts can be of any file type and any number of them can be declared in a single module.

In the Java world, common artifacts are Java archives or JAR files. In many cases, each revision of a module publishes only one artifact (like jakarta-log4j-1.2.6.tar.gz, for instance), but some of them publish many artifacts depending on the use of the module (like apache-ant binary and source distributions in zip, gz and bz2 package formats, for instance).

Examples: ant-1.7.0-bin.zip, apache-ant-1.7.0-src.tar.gz

A module configuration is a way to use or construct a module. 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.

For more details on configurations and how they are used in Ivy, please refer to the main concepts page.

Ivy settings files are XML files used to configure Ivy to indicate where the modules can be found and how.

What is called a repository in Ivy is a distribution site location where Ivy is able to find your required modules' artifacts and descriptors (i.e. Ivy files in most cases).

Ivy can be used with complex repositories configured very finely. You can use Dependency Resolvers to do so.

A dependency resolver is a pluggable class in Ivy which is used to:

The notion of artifact "downloading" is large: an artifact can be on a web site, or on the local file system of your machine. The download is thus the act of bring a file from a repository to the Ivy cache.

Moreover, the fact that it is the responsibility of the resolver to find Ivy files and download artifacts helps to implement various resolving strategies.

As you see, a dependency resolver can be thought of as a class responsible for describing a repository.

If you want to see which resolvers are available in Ivy, you can go to the resolvers configuration page.

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.

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.

For details on how to declare your module configurations, how to declare in which configuration your artifacts are published, and how to declare configuration mapping, please refer to Ivy file documentation. The configurations tutorial is also a good place to go to learn more about this concept.

During configuration, Ivy allows you to define what are called Ivy variables. Ivy variables can be seen as Ant properties, and are used in a very similar way. In particular, you use a properties tag in the settings file to load a properties file containing Ivy variables and their values.

But the main differences between Ant properties and Ivy variables are that Ivy variables can be overridden, whereas Ant properties can’t, and that they are defined in separate environments.

Actually all Ant properties are imported into Ivy variables when the configuration is done (if you call Ivy from Ant). This means that if you define an Ant property after the call to configure, it will not be available as an Ivy variable. On the other hand, Ivy variables are NOT exported to Ant, thus if you define Ivy variables in Ivy, do not try to use them as Ant properties.

To use Ivy variables, you just have to follow the same syntax as for Ant properties: ${variablename} where variablename is the name of the variable.

Finally, it’s also important to be aware of the time of substitution of variables. This substitution is done as soon as possible. This means that when Ivy encounters a reference to a variable, it tries to substitute it if such a variable is defined. Consequently, any later modification of the variable will not alter the value already substituted.

Moreover, in an Ant environment, a bunch of variables are going to be set by default via the Ant property file loading mechanism (actually they are first loaded as Ant properties and then imported as Ivy variables, see Ant Tasks), and even in the Ant properties themselves there is going to be eager substitution on loading, effectively making it impossible to override some variable purely via the ivysettings.properties file. Some variables will really only be able to be overridden via Ant properties because of this.

Moreover, it’s also important to understand the difference between Ivy variables and Ivy pattern tokens. See the Patterns chapter below for what pattern tokens are.

Ivy patterns are used in many dependency resolvers and Ivy tasks, and are a simple way to structure the way Ivy works.

First let’s give an example. You can, for instance, configure the file system dependency resolver by giving it a pattern to find artifacts. This pattern can be like this: myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]

This pattern indicates that the repository we use is in a directory called myrepository.

In this directory we have directories having for name the name of the organisation of the module we look for. Then we have a directory per module, each having for name the name of the module. Then in module directories we find a directory per artifact type (jars, wars, ivys, …​), in which we find artifacts named by the artifact id, followed by a hyphen, then the revision, a dot, and the artifact extension. Not too difficult to understand is it? That’s it, you have understood the pattern concept!

To give a bit more explanation, a pattern is composed of tokens, which are replaced by actual values when evaluated for a particular artifact or module. Those tokens are different from variables because they are replaced differently for each artifact, whereas variables are usually given the same value.

You can mix variables and tokens in a pattern: ${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]

The tokens available depends on where the pattern is used (will it be evaluated with artifacts or modules, for instance). But here are all the tokens currently available:

The difference between type and extension is explained in the Ivy file documentation.

(since 1.2) [organization] can be used instead of [organisation].

(since 1.3) Optional parts can be used in patterns.

This provides the possibility to avoid some input when a token is not defined, instead of having only the token as blank. Parenthesis are used to delimit the optional part, and only one token can be found inside the parenthesis.

So if you surround a token with ( and ), any other text which is between the parenthesis will be ignored if the token has no value.

For instance, suppose the pattern: abc(def[type]ghi)

A more real life example: The pattern [artifact](-[revision]).[ext] lets you accept both myartifact-1.0.jar when a revision is set, and myartifact.jar (instead of myartifact-.jar) when no revision is set. This is particularly useful when you need to keep control of artifact names.

(since 1.4) Extra attributes can be used as any other token in a pattern.

Ivy often needs to know which revision between two is considered the "latest". To know that, it uses the concept of latest strategy. Indeed, there are several ways to consider a revision to be the latest. You can choose an existing one or plug in your own.

But before knowing which revision is the latest, Ivy needs to be able to consider several revisions of a module. Thus Ivy has to get a list of files in a directory, and it uses the dependency resolver for that. So check if the dependency resolver you use is compatible with latest revisions before wondering why Ivy does not manage to get your latest revision.

Finally, in order to get several revisions of a module, most of the time you need to use the [revision] token in your pattern so that Ivy gets all the files which match the pattern, whatever the revision is. It’s only then that the latest strategy is used to determine which of the revisions is the latest one.

Ivy has three built-in latest strategies:

See also how to configure new latest strategies here.

A conflict manager is able to select, among a list of module revisions in conflict, a list of revisions to keep. Yes, it can select a list of revisions, even if most conflict managers select only one revision. But in some cases you will need to keep several revisions, and load in separate class loaders, for example.

A list of revisions is said to be in conflict if they correspond to the same module, i.e. the same organisation/module name couple.

The list of available conflict managers is available on the conflict manager configuration page.

For more details on how to setup your conflict managers by module, see the conflicts section in the Ivy file reference.

(since 1.3) In several places Ivy uses a pattern to match a set of objects. For instance, you can exclude several modules at once when declaring a dependency by using a pattern matching all the modules to exclude.

Ivy uses a pluggable pattern matcher to match those object names. 3 are defined by default:

Note also that with any matcher, the character '*' has the special meaning of matching anything. This is particularly useful with default values which do not depend on the matcher.

(since 1.4) Several tags in Ivy XML files are extensible with what is called extra attributes. The idea is very simple: if you need some more information to define your modules, you can add the attribute you want and you will then be able to access it as any other attribute in your patterns.

(since 2.0) It’s possible and recommended to use XML namespaces for your extra attributes. Using an Ivy extra namespace is the easiest way to add your own extra attributes.

Example: here is an Ivy file with the attribute color set to blue:

Then you must use the extra attribute when you declare a dependency on foo. Those extra attributes will indeed be used as identifiers for the module like the org, the name and the revision:

And you can define your repository pattern as:

Note that in patterns you must use the unqualified attribute name (no namespace prefix).

If you don’t want to use XML namespaces, it’s possible but you will need to disable Ivy file validation, since your files won’t fulfill anymore the official Ivy XSD. See the settings documentation to see how to disable validation.

(since 1.4) Ivy allows the use of checksums, also known as digests, to verify the correctness of a downloaded file.

The configuration of using the algorithm can be done globally or by dependency resolver. Globally, use the ivy.checksums variable to list the check to be done. On each resolver you can use the checksums attribute to override the global setting.

The setting is a comma separated list of checksum algorithms to use. During checking (at download time), the first checksum found is checked, and that’s all. This means that if you have a "SHA-256, sha1, md5" setting, then if Ivy finds a SHA-256 file, it will compare the downloaded file SHA-256 against this SHA-256, and if the comparison is ok, it will assume the file is ok. If no SHA-256 file is found, it will look for an sha1 file. If that isn’t found, then it checks for md5 and so on. If none is found no checking is done. During publish, all listed checksum algorithms are computed and uploaded.

By default checksum algorithms are "sha1, md5".

If you want to change this default, you can set the variable ivy.checksums. Hence, to disable checksum validation you just have to set ivy.checksums to "".

(since 1.4) When Ivy performs the dependency resolution and some other tasks, it fires events before and after the most important steps. You can listen to these events using Ivy API, or you can even register a trigger to perform a particular action when a particular event occur.

This is a particularly powerful and flexible feature which allows, for example, you to perform a build of a dependency just before it is resolved, or follow what’s happening during the dependency resolution process accurately, and so on.

For more details about events and triggers, see the triggers documentation page in the configuration section of this documentation.

(since 1.4) Circular dependencies can be either direct or indirect. For instance, if A depends on A, it’s a circular dependency, and if A depends on B which itself depends on A, this is also a circular dependency.

Prior to Ivy 1.4 circular dependencies caused a failure in Ivy. As of Ivy 1.4, the behaviour of Ivy when it finds a circular dependency is configurable through a circular dependency strategy.

3 built-in strategies are available:

See the configuration page to see how to configure the circular dependency strategy you want to use.

Ivy heavily relies on local caching to avoid accessing remote repositories too often, thus saving a lot of network bandwidth and time.

As a dependency manager, Ivy has a lot of file related operations, which most of the time use paths or path patterns to locate the file on the filesystem.

These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don’t have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths. For instance, Ivy has a concept of base directory, which is basically the same as for Ant. You have access to this base directory with the ivy.basedir variable. So if you have a path like ${ivy.basedir}/ivy.xml, you have an absolute path. In settings files, you also have a variable called ivy.settings.dir which points to the directory in which your settings file is located, which makes defining paths relative to this directory very easy.

If you really want to use relative paths, the base directory used to actually locate the file depends on where the relative path is defined:

Most of the artifacts found in a repository are jars. They can be downloaded and used as is. But some other kind of artifacts required some unpacking after being downloaded and before being used. Such artifacts can be zipped folders and packed jars. Ivy supports that kind of artifact with packaging.

A packaged artifact needs to be declared as such in the module descriptor via the attribute packaging. The value of that attribute defined which kind of unpacking algorithm must be used. Here are the list of currently supported algorithms:

So, if in an ivy.xml, there would be declared a such artifact:

A file mymodule-1.2.3.jar.pack.gz would be download into the cache, and also uncompressed in the cache to mymodule-1.2.3.jar. Then any post resolve task which supports it, like the cachepath, will use the uncompressed file instead of the original compressed file.

It is possible to chain packing algorithm. The attribute packaging of a artifact expects a comma separated list of packing types, in packing order. For instance, an artifact mymodule-1.2.3.jar.pack.gz can have the packaging jar,pack200, so it would be uncompressed as a folder mymodule-1.2.3.

Very often some concepts discussed in Ivy here, and especially those involving modules and dependencies, require to be discussed by text (e-mail, textual doc, console, …​), and so benefit from convention in this area.

The conventions have been adopted with Ivy 2.0 are the following:

Another usual text representation used is to represent dependencies using a dash followed by greater than sign: ->

To group a set of set of modules, we recommend using curly braces { }.

With these conventions, it’s easy to give a concise and detailed overview of a set of modules and their dependencies.

For instance:

In full words here is how it could be written:

As you can see, using text conventions is much more concise.

Another benefit is that these conventions are usually used in Ivy console output, and can also be used in some cases to be parsed into Ivy objects (we use it for test cases, for instance). To make sure text parsing works fine, we recommend using only a limited range of characters for each attributes of your module identifiers.

Here is the recommended characters set for each attribute:

Now that you have been introduced to the main Ivy terminology and concepts, it is time to give some explanation of how Ivy works.

More details on ant tasks here.

Ivy needs to be configured to be able to resolve your dependencies. This configuration is usually done with a settings file, which defines a set of dependency resolvers. Each resolver is able to find Ivy files and/or artifacts, given simple information such as organisation, module, revision, artifact name, artifact type and artifact extension.

The configuration is also responsible for indicating which resolver should be used to resolve which module. This configuration is dependent only on your environment, i.e. where the modules and artifacts can be found.

A default configuration is used by Ivy when none is given. This configuration uses an ibiblio resolver pointing to https://repo1.maven.org/maven2/ to resolve all modules.

The resolve time is the moment when Ivy actually resolves the dependencies of one module. It first needs to access the Ivy file of the module for which it resolves the dependencies.

Then, for each dependency declared in this file, it asks the appropriate resolver (according to settings) to find the module (i.e. either an Ivy file for it, or its artifacts if no Ivy file can be found). It also uses a filesystem based cache to avoid asking for a dependency if it is already in cache (at least if possible, which is not the case with latest revisions).

If the resolver is a composite one (i.e. a chain or a dual resolver), several resolvers may actually be called to find the module.

When the dependency module has been found, its Ivy file is downloaded to the Ivy cache. Then Ivy checks if the dependency module has dependencies, in which case it recursively traverses the graph of dependencies.

All over this traversal, conflict management is done to prevent access to a module as soon as possible.

When Ivy has traversed the whole graph, it asks the resolvers to download the artifacts corresponding to each of the dependencies which are not already in the cache and which have not been evicted by conflict managers. All downloads are made to the Ivy cache.

Finally, an XML report is generated in the cache, which allows Ivy to easily know what are all the dependencies of a module, without traversing the graph again.

After this resolve step, two main steps are possible: either build a path with artifacts in the cache, or copy them to another directory structure.

What is called retrieve in Ivy is the act of copying artifacts from the cache to another directory structure. This is done using a pattern, which indicates to Ivy where the files should be copied.

For this, Ivy uses the XML report in the cache corresponding to the module it should retrieve to know which artifacts should be copied.

It also checks if the files are not already copied to maximize performances.

In some cases, it is preferable to use artifacts directly from the cache. Ivy is able to use the XML report generated at resolve time to build a path of all artifacts required.

This can be particularly useful when building plug-ins for IDEs.

Ivy is also able to generate readable reports describing the dependencies resolution.

This is done with a simple XSL transformation of the XML report generated at resolve time.

Finally, Ivy can be used to publish a particular version of a module in your repository, so that it becomes available for future resolving. This task is usually called either manually or from a continuous integration server.

Here are some recommendations and best practices we have gathered throughout our experience and consultancies with our customers.

In Ivy world, module descriptors are Ivy files, which are basically simple XML files describing both what the module produces as artifacts and its dependencies.

It is a good practice to write or download module descriptors for all the modules involved in your development, even for your third party dependencies, and even if they don’t provide such module descriptors themselves.

First, it will seem like extra work and require time. But when you have several modules using the same third party library, then you will only need to add one line to your Ivy file to get this library and all its own dependencies that you really need (if you have good module descriptors in your repository, especially with the use of module configurations). It will also be very helpful when you want to upgrade a dependency. One single change in your module Ivy file and you will get the updated version with its updated (or not) dependencies.

Therefore we recommend adding Ivy files for all the modules in your repository. You can even enforce this rule by setting the descriptor attribute to required on your resolvers. Hence you shouldn’t need to use the dependency artifact inclusion/exclusion/specification feature of Ivy, which should only be used in very specific cases.

This is usually not a valid recommendation for open source projects, but for the enterprise world we strongly suggest to avoid relying on a public repository like Maven ibiblio or ivyrep. Why? Well, there are a couple of reasons:

Ivy is very flexible and can accommodate a lot of existing repositories, using the concept of patterns. But if your repository doesn’t exist yet, we strongly recommend always using the organisation and the module name in your pattern, even for a private repository where you put only your own modules (which all have the same organisation). Why? Because the Ivy listing feature relies on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won’t be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like install or repreport.

If you create a public repository, provide a URL to the ivysettings.xml file. It’s pretty easy to do, and if someone wants to leverage your repository, (s)he will just have to load it with settings with the URL of your ivysettings.xml file, or include it in its own settings file, which makes it really easy to combine several public repositories.

Very often, especially when working in a team or with several modules, you will need to rely on intermediate, non-finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework.

If you follow the continuous integration paradigm across modules, these integration versions can be produced by a continuous integration server, very frequently.

So, how can you deal with these, possibly numerous, integration versions?

There are basically two ways to deal with them, both ways being supported by Ivy:

So, which way is the best? As often, it depends on your context, and if one of the two was really bad it wouldn’t be supported in Ivy :-)

But usually we recommend using the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make all your builds reproducible, even integration ones. And this is interesting because it enables, with some work in your build system, the ability to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release.

Imagine you have a customer who comes on a Monday morning and asks for the latest version of your software, for testing or demonstration purposes. Obviously he needs it for the afternoon :-) Now if you have a continuous integration process and good tracking of your changes and your artifacts, it may occur to you that you are actually able to fulfill his request without needing the use of a DeLorean to give you some more time :-) But it may also occur to you that your latest version is stable enough to be used for the purpose of the customer, but was actually built a few days ago, because the very latest just broke a feature or introduced a new one you don’t want to deliver. You can deliver this 'stable' integration build if you want, but rest assured that a few days, or weeks, or even months later, the customer will ask for a bug fix on this demo only version. Why? Because it’s a customer, and we all know how they are :-)

So, with a build promotion feature of any build in your repository, the solution would be pretty easy: when the customer asks for the version, you not only deliver the integration build, but you also promote it to a milestone status, for example. This promotion indicates that you should keep track of this version for a long period, to be able to come back to it and create a branch if needed.

Unfortunately Ivy does not by its own allow you to have such reproducible builds out of the box, simply because Ivy is a dependency manager, not a build tool. But if you publish only versions with a distinct name and use Ivy features like versions constraint replacement during the publication or recursive delivery of modules, it can really help.

On the other hand, the main drawback of this solution is that it can produce a lot of intermediate versions, and you will have to run some cleaning scripts in your repository unless your company name starts with a G and ends with oogle :-)

With Ivy 1.4 you can resolve a dependency without even writing an Ivy file. This practice is called inlining. But what is it good for, and when should it be avoided?

Putting Ivy dependencies in a separate file has the following advantages:

On the other hand, using inline dependencies is very useful when:

Build and dependency management is often given too low a priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money savings in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured.

Therefore hiring a build and dependency expert to analyse and improve your build and release system is most of the time a very good choice.

These best practices reflect our own experience, but we do not pretend to own the unique truth about dependency management or even Ivy use.

So feel free to comment on this page to add your own experience feedback, suggestions or opinion.

Up to Ivy 2.3.x, a minimum of Java 1.4 is required.

For Ivy 2.4.0, a minimum of Java 5 is required.

Since Ivy 2.5.0, a minimum of Java 7 is required.

Ivy doesn’t require a specific version of Ant as long as the Ant being used complies with the JVM compatibility requirements noted above.

The required versions of the Apache HttpClient, Jsch or any optional dependency are to be checked against Ivy’s dependency descriptor. In Ivy’s source, check for the ivy.xml file at the root. Or the pom.xml of org.apache.ivy#ivy in the Maven Central repository.

Ivy does not at this time support multithreaded use. It thus should not be used with the Ant <parallel> task.

There are basically two ways to install Ivy: either manually or automatically.

Download the version you want here, unpack the downloaded zip file wherever you want, and copy the Ivy jar file into your Ant lib directory (ANT_HOME/lib).

If you use Ant 1.6.0 or superior, you can then simply go to the src/example/hello-ivy dir and run Ant: if the build is successful, you have successfully installed Ivy!

If you use Ant 1.5.1 or superior, you have to modify the build files in the examples:

If the build is not successful, check the FAQ to see what might be the problem with the ivyrep resolver.

If you want to use Ivy only in your Ant build scripts, and have an internet connection when you build, you can download Ivy from this site and use the downloaded version automatically, using this simple build snippet:

Then the only thing to do is to add the init-ivy target in the depends attribute of your targets using Ivy, and add the ivy namespace to your build script. See the self contained go-ivy example for details about this.

The settings file is structured in some parts and left open in others. In fact, each resolver has its own structure, thus it’s not the settings file itself which defines the structure for the resolvers.

ivysettings

Tag: ivysettings

Root tag of any Ivy settings file.

Sets the variable myvar to the value myvalue.

Sets the variable myvar to the value myvalue only if myvar has not been set yet.

If the environment variable is set, it takes precedence over of default value.

with ivysettings-default.xml:

The included Ivy settings defines a resolver named default, which is an ivyrep resolver, with its root configured as being the value of myrepository variable. This variable is given the value path/to/rep in the included file, but because the attribute overwrite is set to false, it will not override the value given in the main Ivy settings including this one, so the value used for myrepository will be path/to/my/real/rep.

with ivysettings-macro.xml being the Ivy settings example given on the macrodef documentation page. This lets us easily reuse the custom macro resolver.

Adds the custom-resolver.jar (found in the same directory as the ivysettings.xml file) to the classpath, then defines a custom resolver and uses it.

Same as above, but finds the jar on a web server.

Defines a detached signature generator with name 'mypgp' which uses the secret key ring on the default location and automatically selects a private key.

Same as before, but this time the key 123ABC45 is used to generate the detached signature.

Define 2 cache instances, named mycache and mycache2, using two different directories as base directory, and using the default patterns and lock strategies. The default cache instance will still be defined as long as at least one dependency resolver does not declare which cache manager to use.

Defines a cache called mycache, storing files in the /path/to/mycache directory using [module]/ivy-[revision].xml as a pattern to store Ivy files and [module]/[artifact]-[revision].[ext] as a pattern to store other artifacts. The lock strategy used by this cache is the no-lock strategy, which does not perform any locking. The defaultTTL used is 1 s, meaning that by default dynamic revision result will be stored and used for one second. TTL rules then define that all latest.integration revisions will be stored and used for 200 ms, while other dynamic revisions from org1 org2 and org3 modules will be stored respectively for 10 minutes 20 seconds; 5 hours; and 2 days and 12 hours.

[since 1.4]

The latest-revision can now be configured to handle more words with special meanings than the one defined in PHP version_compare function.

Here is an example of how you can do so:

Knowing that the default "special meaning" words are the following:

You can even remove or redefine the default special meanings by setting usedefaultspecialmeanings="false" on the latest-revision tag. Example:

Tag: namespace

Defines a new namespace. A namespace is identified by a name, which can be referenced by one of the resolvers.

An overview of namespaces is given in the namespaces documentation.

A namespace mainly consists of a list of rules, each rule defining a translation between a system namespace and the defined namespace, and vice versa.

There are two main possibilities for using these rules. By default, a namespace iterates through the rules, and when it finds one that translates the given name, it returns the translated name. But the namespace can be configured to use the list as a translator chain: in this case, all rules are applied in order, the result of the first rule translation being passed to the second, and so on.

Matches modules from systemorg2 which have a name beginning with system followed by a minus and anything else, and translate it to organisation B and module the part following system- of the original name.

Since you can use the same macro several times it can define several resolvers (in a chain, for instance), the resolver names need to be chosen carefully to avoid name conflicts (each resolver must have a unique name).

Here is how Ivy deals with the names of the resolvers defined in a macro:

Example:

This is equivalent to:

Defining a simple macro:

Using it:

A complete example:

Ivy comes with a set of built-in dependency resolvers that handle most common needs.

If you don’t find the one you want here, you can also check if someone has contributed it on the links page, or even write your own.

There are basically two types of resolvers in Ivy - composite and standard. A composite resolver is a resolver which delegates the work to other resolvers. The other resolvers are standard resolvers.

Here is the list of built-in resolvers:

All resolvers of the same type share some common features and attributes detailed here.

Defines a filesystem resolver, named 1, which is then used in two chains, the first combining the filesystem resolver with an ivyrep resolver, and second combining the filesystem resolver with an ibiblio resolver, which returns the first module found, and uses the whole chain to download artifacts (see corresponding resolvers documentation for details about them). Resolver 1 will use a cache named cache-1 which should have been defined in the caches element.

This resolver shares the common attributes of standard resolvers.

Looks for Ivy files in an ivyrep like web site located at http://ivyrep.mycompany.com.

This resolver shares the common attributes of standard resolvers.

Defines a resolver called maven2 using the Maven 2 public repository to find module metadata (using Maven 2 POMs) and artifacts.

Same as above, but doesn’t use POMs, only artifacts.

This resolver shares the common attributes of standard resolvers, plus the following:

Setting a resourceURL will cause the resolver to override the URLs for resources specified by the packaging instructions. Instead, all resources will be downloaded from an URL constructed by first resolving the resourceURL pattern into a base URL, and then resolving the resource filename relative to that base URL. In other words, the resourceURL pattern specifies the URL "directory", so it should always end in a forward slash.

If a resourceURL download fails, the resolver will fall back to the original URL from the packaging instructions.

Configure a resourceURL in situations where you don’t want to rely on (or wait for) the web sites configured in the packaging instructions, and have access to a better (perhaps private) mirror site.

Defines a packager resolver which points to the http://ivyroundup.googlecode.com/ online repository. Builds will occur in a subdirectory of ${user.home}/.ivy2/packager/build, downloaded resources will be cached in ${user.home}/.ivy2/packager/cache and the mirror site organisation/[module]/ will be tried first for all resources.

The goal of the packaging instructions is to download the required archives, extract the artifacts, and put the artifacts into a subdirectory. Each artifact should be written to artifacts/[type]s/[artifact].[ext] when the Ant build completes.

Below is an example of packaging instructions for TestNG:

Of course, packaging instructions must produce artifacts consistent with those listed in the associated ivy.xml file.

This resolver ensures that the following Ant properties are defined when it executes the Ant build task.

The packager.xml document element can contain the following child tags.

Which Ant tasks are allowed within the build tag is controlled by the restricted configuration attribute. When true (the default), only the following Ant tasks are allowed: copy, jar, mkdir, move, tar, unjar, untar, unwar, unzip, war, and zip. When false, all Ant tasks are allowed.

Warning: setting restricted to false creates a security problem due to Ant tasks like delete, exec, etc. Do not use this setting when your configuration points to an untrusted repository.

The resource XML tag supports the following attributes:

The resource XML tag may contain child elements. An url tag with an href attribute specifies an alternate URL for the resource (see TestNG example above). Any other tags will be included as children of an automatically generated fileset tag.

Special support is included for Maven 2 resources. For these resources, use the m2resource tag instead of the resource tag. Each m2resource tag specifies one or more artifacts that are downloaded from the Maven 2 repository.

The m2resource XML tag supports the following attributes:

Each m2resource XML tag must have one or more artifact tags that define the artifacts to directly download. The URL for each artifact is constructed automatically based on the attributes in the m2resource and artifact tags.

The artifact children of m2resource tags support the following attributes:

Below is an example of packaging instructions for the Apache Commons Email module. Note that no build tag is required because all of the Maven 2 artifacts are usable directly (i.e., without unpacking anything).

[since 2.0]

This resolver supports atomic publish, which is useful for environments with a lot of concurrent publish and resolve actions. The atomic publish relies on the atomicity of the rename operation in the underlying filesystem (which includes NTFS and POSIX based filesystems). In this case the resolver starts by publishing the module according to the pattern, but where a .part suffix is appended to the revision. Then the publish is committed with a rename to the final location.

Limitations Atomic publish is currently limited in several ways:

The transactional attribute can be used to configure the atomicity behavior:

This resolver shares the common attributes of standard resolvers.

This resolver shares the common attributes of standard resolvers.

Looks for Ivy files in one place and for artifacts in two places: with or without revision in name (revision being already in the directory structure).

This resolver shares the common attributes of composite resolvers.

Both a filesystem and ivyrep will be used to look for Ivy files. If a dynamic revision is required, then both the filesystem and ivyrep will be queried to find the most recent revision among the two resolvers. Once the most recent revision is found in one resolver, it’s the same resolver which will be used to download artifacts.

Same as before, except that if a revision is found in the filesystem then ivyrep will not be queried: its the filesystem which will be used for both the Ivy file and the artifacts.

Same as first example, except that once a module is found by either filesystem or ivyrep, then it’s the whole chain which will be queried to download the artifacts. So in this case Ivy file and artifacts may be split across the two resolvers for the same module.

This resolver shares the common attributes of composite resolvers.

This resolver shares the common attributes of standard resolvers.

Will connect to myhost.com using myuser and prompt for the password.

Will connect to myhost.com using user and password provided with Ivy variables.

Will connect to yourserver.com on port 8022 with user 'user' and password 'geheim' for authentication for Ivy files, and to myserver.com on port 8022 using user 'user' and password 'secret' for the artifacts.

Will connect to yourserver.com on port 8022 with user 'user' and use keyFile path/to/key/file for keyFile and the value of password variable for keyFilePassword authentication for Ivy files, and to myserver.com on port 8022 using user 'user' with the same keyFile/keyFilePassword pair for the artifacts.

Will connect to the host named by myhost according to the config file in /path/to/.ssh/config, using the hostname, username, and optionally IdentityFile specified in the config section "Host myhost". For example, if the corresponding Host section contains "Hostname yourserver.com" and "User myremoteusername", it will connect to yourserver.com using username myremoteusername.

This resolver shares the common attributes of standard resolvers.