Is there a way to specify an Ivy dependency using a dynamic revision but restricting the status?

Is it possible for me to declare a dependency using a dynamic revision while restricting the status of the retrieved artifact? For example, I want to define a version range, something like "[1.0,1.1[", but I don't want artifacts with a status of integration, only milestone or release. S开发者_运维知识库o I want version 1.0.5 if it has a status of "release" even if there's a version 1.0.6 with a status of "integration."

I know about latest.status, but that's not really what I want: I need to define an upper and lower limit on the revision.

Maybe the solution is to define your own version-matcher see http://ant.apache.org/ivy/history/latest-milestone/settings/version-matchers.html

I used it (in ivysettings.xml) to make this:

<!-- Matcher for build with given build number
    It assumes the version number is on the form
    #.#__.# where the lastet '.#' is the build number. -->
<version-matchers usedefaults="true">
    <pattern-vm>
        <match revision="build_number" pattern="[\d\.]+\.${buildnumber}" args="buildnumber" matcher="regexp"/>
    </pattern-vm>
</version-matchers>

You can call it in you build script by setting the revision attribute like 'revision="build_number(${prop.buildnumber})"'

Thanks for asking this question, rsteele. I had a similar question and here is the solution I am using. It works if your range corresponds to sub-revisions:

The easiest way to present this is with an example:

<dependency org="com.acme" name="wigdet" branch="1" rev="latest.milestone">

• 1/ivy-1.0.xml: status="integration"
• 1/ivy-1.1.xml: status="milestone"
• 1/ivy-1.2.xml: status="integration"

The dependency resolves to 1.1.

This works for me but I am not entirely happy with it and I hope someone can point out a better way or poke holes in it:

• branch seems appropriate because com.acme actually has a branch in version control which corresponds to version 1.
• on the other hand branch seems inappropriate because "1" is part of the revision, and perhaps branch is more useful in other ways.
• this doesn't solve the more general problem posed by rsteele.