Ivy dependency management for legacy repository

Question

We have a repository which doesn\'t have ivy.xml and other metadata files. Since, its published by another team which doesn\'t use ivy/maven but will continue to deliver cod

Answer 1

The standard resolvers should be able to pick up the atifacts (url, filesystem, etc). The problem you'll face is that, by default, ivy assumes a revision never changes. Without version information you're going to have tweak the standard resolver settings to force ivy to always check the artifact.

The ivy concepts page explains how this works:

Some people, especially those coming from maven 2 land, like to use one special revision to handle often updated modules. In maven 2 this is called a SNAPSHOT version, and some argue that it helps save disk space to keep only one version for the high number of intermediary builds you can make whilst developing.

Ivy supports this kind of approach with the notion of "changing revision". A changing revision is just that: a revision for which Ivy should consider that the artifacts may change over time. To handle this, you can either specify a dependency as changing on the dependency tag, or use the changingPattern and changingMatcher attributes on your resolvers to indicate which revision or group of revisions should be considered as changing.

Personally I dislike this kind of dependency management. Your build is a moving goal post and it's hard to keep it stable.

I would encourage to to persuade the other team to at least append a build number to each artifact they publish. Your ivy build could then use a dynamic revision to resolve the artifact. The key point is that when you ship your code, your module will have a dependency against a specific version of its 3rd party libraries.

Update

The following is an example project. It uses Maven Central and a local repo, to download its dependencies.

├── build
│   ├── compile
│   │   ├── artifact1.jar   <-- Changing artifact
│   │   └── slf4j-api.jar
│   ├── runtime
│   │   ├── artifact1.jar   <-- Changing artifact
│   │   ├── artifact2.jar   <-- Changing artifact
│   │   ├── log4j.jar
│   │   ├── slf4j-api.jar
│   │   └── slf4j-log4j12.jar
│   └── test
│       ├── artifact1.jar   <-- Changing artifact
│       ├── artifact2.jar   <-- Changing artifact
│       ├── artifact3.jar   <-- Changing artifact
│       ├── hamcrest-core.jar
│       ├── junit.jar
│       ├── log4j.jar
│       ├── slf4j-api.jar
│       └── slf4j-log4j12.jar
├── build.xml
├── ivysettings.xml
└── ivy.xml

The local repo is un-versioned and has no ivy files. Normally the ivy resolvers require ivy files (or POM in the case of Maven) to determine if a remote module has changed. In the absence of metadata you can mark the dependency as changing in the ivy file.

build.xml

Notes:

• Stand build file using ivy. The retrieve task assembles the files into their various configuration groupings.

ivy.xml

Notes:

• The "myorg" dependencies have a dummy "NA" entry as their revision and are marked as "changing".

ivysettings.xml

Notes:

• The "myorg-repo" resolver is setup to download only the "myorg" dependencies. This enables all other dependencies to be resolved by Maven Central.
• The "myorg-repo" resolver just declares an artifact pattern, I'm assuming there are no ivy files to be retrieved.