What's wrong with this Ivy changingPattern / SNAPSHOT configuration?

Question

I can\'t get Ivy to update cache when snapshot dependencies are updated. The resolver (to has the following settings:

Answer 1

I'm not a fan of using the url resolver when talking to Maven repository managers. The problem is Maven has special and rather unique handling for snapshot revisions..... The url resolver is better suited for use against ivy respositories.

I use Nexus, but the following should also apply to Artifactory. The following settings file sets up Maven Central and my two hosted repositories (Maven repositories come in two flavours, release or snapshot):

<ivysettings>
    <settings defaultResolver="repos" />
    <resolvers>
        <chain name="repos">
            <ibiblio name="central" m2compatible="true"/>   
            <ibiblio name="my-releases" m2compatible="true" root="https://myhost/releases"/>   
            <ibiblio name="my-snapshots" m2compatible="true" root="https://myhost/snapshots"/>   
        </chain>
    </resolvers>
</ivysettings>

You'll notice I'm using the ibilio resolver which has internal logic to decipher Maven's special Snapshot handling.

When I require a snapshot revision I think declare it explicitly as follows:

<ivy-module version="2.0">
    <info organisation="myOrg" module="Demo"/>
    <dependencies>
        <dependency org="myOrg" name="myModule" rev="2.7-SNAPSHOT"/>
        ..
    </dependencies>
</ivy-module>

Under the hood the ibilio resolver is reading the Maven repository meta data files to determine which timestamped artifact should be fetched from the snapshot repository.

Update

I would suggest reading the following presentation:

• Continuous delivery with Maven

It outlines pretty well the Maven philosophy separating releases from dev builds (or snapshots). It also explains one of the very clunky aspects of Maven... Two different ways to publish artifacts...

I suspect what you're trying to do is along the lines of the author which is setup a CD pipe-line. In that case every build is a potential release and should be treated as such (No dynamic dependencies which are allowed by snapshots).

I would suggest limiting snapshots to developer only builds. Only deploy release candidates. The problems with this approach will be in managing lots and lots of releases. Some of the repository managers (Nexus, Artifactory, Archiva) offer "staging" features which make it possible to certify or discard releases that don't pass your quality toll-gates.

Update 2

If you are using ivy to publish snapshots into a Maven repository then there are a couple of issues:

• Ivy doesn't support the publication of snapshots with timestamps
• Ivy doesn't update the Maven module's metadata.xml file

In my opinion time-stamped files is one of the killer features of using snapshots in the first place. With ivy it's only possible to provide the latest file (overwriting the previous latest file).

There are work-arounds to address these issues:

1. As suggested in the second link you can ignore metadata completely (setting the "useMavenMetadata" attribute to false) and default back to ivy's older mechanism of comparing file names. This only fixes the problem for ivy clients.
2. The repository manager should be able to regenerate the metadata files (Nexus at least has a task to do this).
3. Use the Maven ANT task.

The last suggestion is not as crazy as it seems. Firstly it's the only way I know to support timestamped snapshots and secondly the Maven client appears to do a lot of extra processing (updating the module metadata) that is largely undocumented.

Answer 2

After days of struggle...

The problem was that for

checkmodified="true" changingMatcher="regexp"

to work on a <resolver>, it has to be on every resolver in the hierarchy line - all parent <chain> resolvers and the <url>, <local>, or <ibiblio> resolver at the bottom.