tags:

views:

463

answers:

1

I've got a main project where module A depends on a a .jar file created by the build for module B. While I'm in development, I'm modifying B regularly, then building B to create the library, then building A to use these changes.

Is there a way to point module A's ivy file to the jar file my module B build creates? Given I'm iterating multiple times, I don't want to check module B's jar into ivy over and over. It's also annoying to have to copy the jar into module A's build directory structure after every module B build.

Actually, for me it's worse, as I have about 4 modules in something of a dependency tree (A->B->CD). If it were just A and B I'd probably just live with it, but I'm getting sick of copying jar files around after the submodule builds and thought if there was a way to override the ivy file dependency line to look locally then that'd make life a lot simpler.

+3  A: 

Pointing the Ivy dependency at your locally built module isn't the way to solve this. Instead when you build module B publish it to your local Ivy repository. When you resolve your dependencies for module A it will pull down module B from your local repository.

From the Ivy docs on the local repository:

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.

The Using Ivy in multiple projects environment documentation has an example publish-local Ant task that you might find useful.

Simon Lieschke