Ivy is a powerful dependencies manager with transitive dependencies support and much more features.
With Ivy you define the dependencies of your module in an xml file, called an ivy file. Then you usually ask ivy to retrieve your dependencies to a local lib dir, and it does it for you by locating the artifacts of your dependencies in repositories, such as ibiblio.
Without a dependencies manager, two solutions are often used to store the dependencies of a project: a project lib dir or direct access to a shared repository. The major drawback of the project lib dir is that the same dependencies are stored in multiple location if you have several projects using the same dependencies. Moreover, we often see project where dependencies revisions are not documented, which can cause problems for maintenance. With the shared repository the problem is often to maintain the list of dependencies of the project. This list is often lost within the build file, which does not help maintenance. Moreover, this solution often requires a download of the whole repository, unless home made dependencies management solution has been used.
Finally, the major drawback of these solutions is that they do not use transitive dependencies. Transitive dependencies are the dependencies of your dependencies. Managing transitive dependencies let you declare dependencies only on what you really need, and not what the module you use themselves need. This not only eases your dependencies declaration, but it also improves a lot the maintenability of your project, especially in multi-project environment. Imagine you develop a component used in several other projects. Then each time your component needs a new dependency, without transitive dependencies, you have to update all the projects using your component ! And this could really take a lot of time !
If you are convinced of using a dependencies manager, you may wonder why using Ivy and not another tool. We are not able to answer this question without being biased, but have a look at Ivy features and the product comparison we provide, and you will certainly see that Ivy is one of the best dependencies manager currently available ;-)
The answer to this question is too long, so it deserves its own page here.
The first thing to do when you don't understand what's going wrong is to try to change the message level. If you use ant, you can use the -debug or -verbose options to get more detailed messages and better understand what's happening.
First, check if the ibiblio site is ok with your favorite browser. If the site is ok, maybe it's a problem of proxy configuration. Set your ANT_OPTS environment variable to configure your proxy if you have one. For instance: set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128
set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128
If it still doesn't work, maybe it's your dependency file which is not ok. Check if the module name you depend on is actually a name of directory under www.ibiblio.org/maven/. If this is the case, check if the jar with a name like [module]-[revision].jar is present under the jars directory of this module on ibiblio. For instance: www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0.jar
If this is the case, check your ivy configuration to see if you actually use the ibiblio or ivyrep resolver.
Finally, you can check if the files were not downloaded but corrupted (Ivy has no md5 checking for the moment) by checking your lib directory and opening the jars if any with an unzip program.
If you still have problems post on the forum mentioning your OS, your version of ant, your version of ivy, your configuration file and your ivy file.
The first thing to do is to ensure the setting is correct. Ivy should log the url it tried, copy this url and paste it in your favorite browser, and verify you get no error.
If this is ok, check if you don't need any proxy setting nor authentication. For proxy setting, you can use for instance this: set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128 For authentication, fill in the appropriate data at configuration time.
If you still have no idea of what is wrong, then I suggest to use commons-httpclient if it isn't already the case (you should just put commons-httpclient in you classpath), and then turn on the debug logging.
You will then have very detailed information on how your url is handled. If you still have problem, ask for help on the forum.
No problem, you just have to set an ant property:
A typical question for people using an IDE like eclipse and often changing dependency revision: it's a bit boring to change your IDE project just to tell him to use comp-build2596.jar instead of comp-build2595.jar, when you have already changed your ivy file (and even if you haven't changed it, if you use the continuous integration feature !). No problem, you have a total control on the files retrieved using the pattern attribute in the retrieve task:
Here is the default pattern:
And here is one which do not suffix file name with dependency revision:
And one which makes your lib directory have the same layout as the ibiblio repository:
Not too difficult, and really flexible, isn't it ? And check the retrieve task reference documentation to learn more about it...
Ivy uses two types of xml files: configuration files and ivy files.
In fact, Ivy distinguishes two different steps to describe and get your dependencies: You write ivy files to describe the dependencies of your module, independently of how you retrieve them. Then you configure ivy to indicate where it can find your dependencies. Thus you can easily share your ivy files, even if you have internal dependencies which are not resolved the same way in your environment as in the target development environment. You just need to write two configuration files, one in your default development environment, and one in the target development environment with the same ivy files.
Ivy uses a concept called configurations to handle this, and many more. As explained in the terminology page, a configuration of your module can be thought as a way to use your module (note: this has nothing to do with the configuration of ivy itself, through the use of configuration file). You can describe what dependencies are needed in each configuration.
Moreover, because the dependencies are modules too, they can also have configurations. What is extremely powerful with ivy is that you can define configurations mapping, i.e. which conf of the dependency is needed in which conf of your module. Thus what is needed at 'runtime' of a dependency can be needed for 'test' of your module.
Finally, the configurations are unlimited, defined in each module, and can extend each other. This contributes a lot to ivy flexibility.
A frequent configuration of Ivy is to use a local repository + ivyrep + ibiblio to store ivy files and artifacts. Here is a sample configuration to do this:
Yes, this is what is called a 'virtual' module.
Having a module which has no publication and only dependencies can be useful in many cases.
In particular, you can in this way define a set of dependencies used in several projects. Once defined, you can simply add a dependency on this virtual module to get all its dependencies, thanks to transitive dependencies management.
It can also be useful if you want to define a flexible framework. In your framework, you will certainly have several modules, each having its own dependencies. But for the users of your framework, it can be interesting to provide a virtual module, representing the framework as a whole, and using configurations to let the user choose what he really wants to use in your framework, in a very flexible and effective way.
But the problem is that ivy considers by default that a module publishes one artifact, with the same name as the module itself. So the way to define a virtual module is to add to its ivy file a publications section with no publication inside:
The problem can come from several places... usually it comes from the fact that some modules on ibiblio do not respect a clean structure.
For instance, opensymphony projects are all in an opensymphony directory, which does not respect the [module]/[artifact]-[revision].[ext] pattern. In this case the only way to go with this is to configure another resolver with the appropriate pattern, and configure ivy to use this resolver for opensymphony only.
Another similar problem is to have several modules in one directory, such xerces and xmlapis in the xerces directory. The problem is that if you consider the two as one module, you will be tempted to declare a dependency on two revisions of this module. This is not the right approach, because this does not match ivy definition of a module. A better approach is similar to the preceding one with a special configuration for this only.
Another solution is to setup a local repository for those modules that are not cleanly deployed on ibiblio. Using this local repository first and the ibiblio repository after is a good way to turn around the problems of ibiblio and still benefit from the huge number of artifacts that can be found.
This the default behaviour of ivy, which relies on the revision and on its cache to avoid too many downloads. However, this can be changed on each resolver using the checkmodified attribute, or globally by setting ivy.resolver.default.check.modified variable to true.
Release notes can be found in the documentation.
If you need more information about Ivy than the one found in the documentation, you can see the links page, use the forum to ask your question to the community, or use your favorite search engine. For search engine search, we advise to use ivy + ant or java as base keywords, since ivy alone is a very common word.