Return-Path: 
 <ivy-user-return-7840-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-ivy-user-archive@www.apache.org
Received: (qmail 34470 invoked from network); 13 Apr 2011 16:03:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 13 Apr 2011 16:03:11 -0000
Received: (qmail 29282 invoked by uid 500); 13 Apr 2011 16:03:10 -0000
Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org
Received: (qmail 29239 invoked by uid 500); 13 Apr 2011 16:03:10 -0000
Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@ant.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@ant.apache.org>
List-Post: <mailto:ivy-user@ant.apache.org>
List-Id: <ivy-user.ant.apache.org>
Reply-To: ivy-user@ant.apache.org
Delivered-To: mailing list ivy-user@ant.apache.org
Received: (qmail 29231 invoked by uid 99); 13 Apr 2011 16:03:10 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Apr 2011 16:03:10 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of
 neil_miller@livewiremobile.com designates 63.173.32.72 as permitted sender)
Received: from [63.173.32.72] (HELO LWMEDGE01.livewiremobile.com)
 (63.173.32.72)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Apr 2011 16:03:05 +0000
Received: from LWMMAIL01.LiveWireMobile.com (10.20.3.2) by
 LWMEDGE01.livewiremobile.com (10.20.3.4) with Microsoft SMTP Server (TLS) id
 8.1.358.0; Wed, 13 Apr 2011 12:02:40 -0400
Received: from [10.21.20.5] (10.21.20.5) by mail.LiveWireMobile.com
 (10.20.3.2) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 13 Apr 2011
 12:02:43 -0400
Message-ID: <4DA5C921.4090102@livewiremobile.com>
Date: Wed, 13 Apr 2011 12:02:41 -0400
From: Neil Miller <neil_miller@livewiremobile.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: "ivy-user@ant.apache.org" <ivy-user@ant.apache.org>
Subject: Re: Using dynamic revision but restrict status?
References: <BANLkTikMY71KMM97SkB3BGcsO53uckvEBA@mail.gmail.com>
 <BANLkTi=yRPSyvx_Ly1LtA5M2ubLVCV0SJQ@mail.gmail.com>
In-Reply-To: <BANLkTi=yRPSyvx_Ly1LtA5M2ubLVCV0SJQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

As far as I know it isn't possible, but it's something I'd like to see 
as well. Unfortunately I haven't had time to write it myself, it looks 
like it might not be too hard...

-n

On 04/13/2011 07:24 AM, Steele, Richard wrote:
> Bump.
>
> This isn't something anyone else has had to deal with?  Or am I missing
> something completely obvious?  Is the answer as simple as "don't ever use
> dynamic revisions?"  If so, then what good are they?
>
> If this isn't currently possible, would an enhancement request be
> worthwhile?  I envision allowing a dependency along the lines of
>
> <dependency org="com.example" name="foo" rev="[1.0,1.1[" status="milestone"
> />
>
> to mean a revision in the specified range with a status of milestone or
> greater.  This would also allow for something like
>
> <dependency org="com.example" name="foo" rev="latest" status="milestone" />
>
> as a synonym for the current "latest.*status*" mechanism.
>
> Thoughts?  Please?
>
> Rich
>
> On Thu, Apr 7, 2011 at 3:13 PM, Steele, Richard<rich@steelezone.net>  wrote:
>
>> 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.  So 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.
>>
>> Thanks,
>> Rich
>>