In the previous tutorial you have seen how to deal with dependencies between two simple projects.
This tutorial will guide you through the use of ivy in a more complete environment. All the sources of this tutorial are available in src/example/multi-project in ivy distribution.
Ivy file of the module, describing its dependencies upon other modules and / or external modules.
Note that this doesn't demonstrate good practice 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 modules build files only import the common build file, and defines their dependencies in their ivy files (which you should begin to be familiar with).
This declaration configures ivy only by setting two properties: the location for the local repository and the location for the shared repository. It's the only settings done here, since ivy is configured by default to work in a team environment (see default settings tutorial for details about this). For sure in a real environment the shared repository location would rather be in a team shared directory (or in a more complex repository, again see the default settings tutorial to see how to use something really different).
Commented out you can see how the settings would have been done if the default settings wasn't ok for our purpose.
You should begin to be familiar with this kind of use of Ivy. We call resolve explicitly to use the ivy file configured (the default would have been fine), and then call retrieve to copy resolved dependencies artifacts from the cache to a local lib directory. The pattern is also used to name the artifacts in the lib dir with their name and extension only (without revision), this is easier to use with an IDE, the IDE configuration won't change when the artifacts version change.
This target is used to ask Ivy to find a new version for a module. To get detailed about the module we are dealing with, we use directly the information found in the ivy file using the ivy:info task. Then the buildnumber task is used to get a new revision, based on a prefix we set with a property, by default it will be 1.0-dev-b (have a look at the default value for module.version.target in the common build properties file). Each module build by this common build file could easily override this by either setting a different module.version.target in its module specific build.properties, or even overriding module.version.prefix. To get the new revision Ivy scans the repository to find the latest available version with the given prefix, and increment this version by 1.
This target publishes the module in the shared repository, with the revision found in the version property, which is set by other targets (based on ivy-new-version we have seen above). It can be used when a module reaches a specific milestone, or whenever you want the team to benefit from a new version of the module.
This is very similar to the publish task, except that this publish the revision in the local repository, which is used only in your environment and doesn't disturb the team. When you change something in a module and want to benefit from the change in another one, you can simply call publish-local in this module, and then your next build of the other module will automatically get this local version.
This target is used when you don't want to use your local version of a module anymore, for example when you release a new version to the whole team, or discard your local changes and want to take advantage of a new version from the team.
after having called report in the console project, and that's it, you have a clear overview of all your app dependencies !
You can see the targets available, thanks to the import of the common.xml build file. Pay with the project by calling resolve, 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 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 is incompatible yet, you can very 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!
You should then be pretty familiar with multi project development with Ivy, we hope you will appreciate its power and flexibility! And those 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 dependency management tool!