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 code frequently.

The jars needed for dependency are stored in flat structure inside a single directory with no revision data. The organization / module /revision structure is absent.

Does ivy allow such dependency resolutions in the core product or will I have to write a custom resolver?

Thanks

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

<project name="demo" default="build" xmlns:ivy="antlib:org.apache.ivy.ant">

   <target name="build" description="do something">
     <ivy:retrieve pattern="build/[conf]/[artifact].[ext]"/>
   </target>

   <target name="clean" description="Cleanup build files">
      <delete dir="build"/>
   </target>

   <target name="clean-all" depends="clean" description="Additionally purge ivy cache">
      <ivy:cleancache/>
   </target>

</project>

Notes:

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

ivy.xml

<ivy-module version="2.0">
    <info organisation="com.myspotontheweb" module="demo"/>

    <configurations>
        <conf name="compile" description="Required to compile application"/>
        <conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
        <conf name="test"    description="Required for test only" extends="runtime"/>
    </configurations>

    <dependencies>
        <!-- compile dependencies -->
        <dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" conf="compile->default"/>
        <dependency org="myorg" name="artifact1" rev="NA" conf="compile->default" changing="true"/>

        <!-- runtime dependencies -->
        <dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" conf="runtime->default"/>
        <dependency org="myorg" name="artifact2" rev="NA" conf="runtime->default" changing="true"/>

        <!-- test dependencies -->
        <dependency org="junit" name="junit" rev="4.11" conf="test->default"/>
        <dependency org="myorg" name="artifact3" rev="NA" conf="test->default" changing="true"/>
    </dependencies>

</ivy-module>

Notes:

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

ivysettings.xml

<ivysettings>
   <settings defaultResolver="central" />
   <resolvers>
      <ibiblio name="central" m2compatible="true"/>
      <url name="myorg-repo">
         <artifact pattern="http://localhost:8080/userContent/[artifact].[ext]"/>
      </url>
   </resolvers>
   <modules>
      <module organisation="myorg" resolver="myorg-repo"/>
   </modules>
</ivysettings>

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.

Answer 2

Understanding ivy pattern helped me resolve the issue. The catch is never specify an ivy pattern whenever the repository doesn't have ivy files.