artifactory - 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:

<url name="xxx" m2compatible="false" 
     checkmodified="true" changingMatcher="regexp" 
     changingPattern=".*-SNAPSHOT.*">

An example artifact filename (in Artifactory) is:

my-jar-1.999-SNAPSHOT.jar

A detailed Ant log of resolve includes:

[NOT REQUIRED] com.myorg#my-module;1.999-SNAPSHOT!my-jar.jar

There is no POM on the artifact.

The resolver is underneath a chain resolver; they both have all the relevant attributes set. I have read https://issues.apache.org/jira/browse/IVY-938 and https://issues.apache.org/jira/browse/IVY-1221, including all the comments, and AFAICT (perhaps incorrectly!) none of the workarounds are relevant.

Should I give up on snapshots and just use explicit versions with "integration.latest" dynamically versioned dependencies? I fear this may end up failing when we have integration builds happening for multiple major versions. At that point we'll need to split the major versions out into separate repositories, or put the major build number in the artifact name, or something equally clunky, just to make "integration.latest" work.

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.