Adjusting default settings

The local repository is particularly useful when you want to do something without being disturbed by anything else happening in the environment. This means that whenever Ivy is able to locate a module in this repository it will be used, no matter what is available in others.

For instance, if you have a module declaring a dependency on the module foo with a revision of latest.integration, then if a revision of foo is found in the local repository, it will be used, even if a more recent revision is available in other repositories.

This may be disturbing for some of you, but imagine you have to implement a new feature on a project, and in order to achieve that you need to modify two modules: you add a new method in module foo and exploit this new method in module bar. Then if you publish the module foo to your local repository, you will be sure to get it in your bar module, even if someone else publishes a new revision of foo in the shared repository (this revision not having the new method you are currently adding).

But be careful, when you have finished your development and publish it on the shared repository, you will have to clean your local repository to benefit from new versions published in the shared repository.

Note also that modules found in the local repository must be complete, i.e. they must provide both a module descriptor and the published artifacts.

As its name suggest, the shared repository is aimed to be shared among the whole development team. It is a place where you can publish your team’s private modules, and it’s also a place where you can put modules not available in the public repository. You can also put modules here that are simply inaccurate in a public repository (bad or incomplete module descriptors, for instance).

Note that modules can be split across the shared repository and the public one: for example, you can have the module descriptor in the shared repository and the artifacts in the public one.

The public repository is the place where most modules can be found, but which sometimes lack the information you need. It’s usually a repository available through an Internet connection only, even if this is not mandatory.

By default, the local repository lies in ${ivy.default.ivy.user.dir}/local. This is usually a good place, but you may want to modify it. No problem, you just have to set the ivy.local.default.root Ivy variable to the directory you want to use:

For example:

If you already have something you would like to use as your local repository, you may also want to modify the layout of this repository. Once again, two variables are available for that:

For example:

By default, the shared repository lies in ${ivy.default.ivy.user.dir}/shared. This is fine if you work alone, but the shared repository is supposed to be, mmm, shared! So changing this directory is often required, and it is usually modified to point to a network shared directory. You can use the ivy.shared.default.root variable to specify a different directory. Moreover, you can also configure the layout with variables similar to the ones used for the local repository:

For example:

By default, the public repository is ibiblio in m2 compatible mode (in other words, the Maven 2 public repository).

This repository has the advantage of providing a lot of modules, with metadata for most of them. The quality of metadata is not always perfect, but it’s a very good start to use a tool like Ivy and benefit from the power of transitive dependency management.

Despite its ease of use, we suggest reading the Best practices to have a good understanding of the pros and cons of using a public unmanaged repository before depending on such a repository for your enterprise build system.