Question

I am trying to revise my build process to use ant with apache ivy for my personal projects. These consist of a few shared modules, and a few application modules that depend on the shared modules. For the sake of this post, let’s simplify and say I have a shared module (common), and an application module (application) which depends on common. Each module has it’s own effective svn repository:

svn_repo_1/common/trunk
                 /branches
                 /tags
svn_repo_2/application/trunk
                      /branches
                      /tags

I check out the relevant revision into a common workspace, in a flat structure:

workspace/common
workspace/application

In general, application will depend on a published version of common, so there will be no need to build common when building application.

However, when I need to add new functionality to common that is required by application, I would then like application to depend on the latest common build from my workspace (without needing to publish common to my repository).

I assumed this is what latest.integration meant (i.e. changing application‘s ivy.xml to specify latest.integration for the common revision). My intention was to use the ivy buildlist task to find the local modules that needed to be built before application could be built. This does not work however, because the buildlist task seems to include the common/build.xml entry regardless of whether application’s ivy.xml file specifies latest.integration or some other published revision.

I would appreciate any suggestions. I am struggling with ivy’s documentation and samples, so any real-world examples would also be helpful. Note: I am not interested in a Maven solution here.

Answer 1

Wow, this is truly deja vu! Go back to some of my first questions on this site from 3 – 4 months ago and they’re almost all Ivy-related! I empathize with you 100% that Ivy is a difficult beast to learn and tame, but after using it professionally for a few months now, I’ll never develop without it again. So my first piece of advice: keep going. Sooner or later, what little (practical) documentation you find on Apache Ivy will alll start to make sense and fall into play.

I can understand there may be extenuating reasons for why you don’t want to publish your common to your repo. However, if you are a newcome to transitive dependency management, the first piece of practical advice I can give you is that you should always publish your JARs/WARs/whatever to your repo; not an intermediary “integration” local to your workspace.

The reason for this is simple: Ivy only has the ability to crawl the repositories you define in your settings file (basically). If you deliberately keep a JAR like common outside of one of these defined repositories, then: (a) Ivy has no way to resolve transitive dependencies (its primary job), and (b) “downstream” (dependent) JARs fail to be dynamically updated every time you tweak common. Thus, using Ivy only to not publish JARs is a bit counter-productive; I’m surprised Ivy even includes it as a feature.

I guess I would need to understand your motivation for not publishing common. If you’re simply having problems getting the ivy:publish task to work, no worries I can provide plenty of examples to help get you started. But if there are some other reasons, then I ask you to consider this solution: set up multiple repositories.

Perhaps you have one “primary” repository where mostly everything gets published; and then you have a “secondary” or “intermediary” repository where you publish common to whenever it makes sense (for you) to do that. You can then configure your Ant build with two different publish tasks, such as publish-main and publish-integration.

That way you get the best of both worlds: you get your intermediary staging area, and you get to keep everything inside of Ivy’s powerful control.