Project Ivy Instance

The project ivy instance is in charge to configure ivy for your project (configure repositories used to retrieve your projects dependencies for example).

In order to work as you want, EasyAnt sometimes need some settings. Actually, EasyAnt can work with no specific settings at all, see the default settings documentation for details about that. Ivy is able to work in very different contexts. You just have to configure it properly.

Settings are specified through an xml file, usually called ivysettings.xml.
Here is an example of settings file :

<ivysettings>
        <properties file="${ivy.settings.dir}/ivysettings-file.properties" />
        <settings defaultCache="${cache.dir}" defaultResolver="ibiblio" checkUpToDate="false" />
        <resolvers>
                <ibiblio name="ibiblio" />
                <filesystem name="internal">
                        <ivy pattern="${repository.dir}/[module]/ivy-[revision].xml" />
                        <artifact pattern="${repository.dir}/[module]/[artifact]-[revision].[ext]" />
                </filesystem>
        </resolvers>
        <modules>
                <module organisation="jayasoft" name=".*" resolver="internal" />
        </modules>
</ivysettings>

Mainly, the settings enable to configure the default cache directory used by ivy and the dependency resolvers that it will use to resolve dependencies.

Note: To work, this settings file needs a property file named ivysettings-file.properties in the same directory as the settings file, with ivy variables you want in it.

If you want to have more details on this settings file we strongly recommend you to read the reference documentation of settings file

How to configure a custom project ivy settings ?

If you just need to add a resolver for your current project you just need to put a "valid" ivysettings.xml file a the root level of your project.

If this doesn't feel your need because you need to factorise this configuration somewhere you can still configure the location of this file through proeprties:
Example:
a property pointing to a file:

   <ea:property name="project.ivy.settings.file" value="/path/to/ivysetings.xml"/>

or a property pointing to an URL:

  <ea:property name="project.ivy.settings.url" value="http://url/to/ivysetings.xml"/>

If no one is specified, easyant will use the default one provided by ivy. See above to have more details.

Default configuration of project ivy instance

This default settings mainly consist of 3 kind of repositories:

local: a repository which is private to the user.
shared: a repository which is shared between all the member of a team public
public: a repository on which most modules, and especially third party modules, can be found

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

Now let's describe each of these repositories concept in more details. We will describe how they are setup physically later.

Local

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 of what is available in others.

For instance, if you have a module declaring a dependency on the module foo in revision 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 publish 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 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.

Shared

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

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

Public