In this first step we use the [[ant:install]] task to install modules from the maven 2 repository to a file system based repository. We first install a module with no dependency, then a module with its dependencies.
Basic: ivysettings.xml file used
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 [[settings/include included]] settings, used by the development team.
install a simple module with no dependencies
Let's have a look at the
maven2
target.
Pretty simple, we call the [[ant:install] task with the settings we have loaded using [[ant:settings ivy:settings]] as usual, we provide fromResolver (source) and toResolver (destination) using properties to 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 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 will use this repository to resolve modules.
install a module with dependencies
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 on 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 target called 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, if you look at the log you will see that there are missing artifacts on 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 use a best effort algorithm during install, so that you have everything installed but the missing artifacts. You may also have notice that Ivy has installed 2 different revisions of commons-logging (1.0.2, 1.0.4). This is due to the fact that we use the "no conflict" [[settings/conflict-managers conflict manager]] in the ivysettings 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 other 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 don't have installed). 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 replication of the original one. Let's have a look at one module content:
[
]
As you can see there is no pom here (pom is the module metadata format used by maven 2, available on 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 grain exclusions and transitivity control, per module conflict manager, ...). Ok, enough for this simple repository installation, the [[tutorial/build-repository/advanced next tutorial]] will now show how you can deal with more complex cases where your source and destination repositories do not follow the same naming conventions.