ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garima Bathla <>
Subject Re: Ivy confs masquerading as dependencies' revisions
Date Fri, 26 Jun 2009 15:28:49 GMT
Thanks, Maarten. I'm familiar with dynamic revisions, but I'm straining to
figure out how they would help in this situation.

Suppose the following:
* I've published both JUnit 3.8.2 and JUnit 4.6 to my Ivy repository.
* I've managed to specify a dynamic revision in my own module's dependency
on JUnit that encompasses both 3.8.2 and 4.6. (I'm not sure there's a way to
specify only 3.8.2 and 4.6 and nothing else without resorting to plugging in
a custom version matcher. But let's set aside that issue for now.)
* I am developing another Ivy module that depends on the Ivy module I've
just published, the one that depends on JUnit.

In the module I'm developing--the one that depends only indirectly on JUnit,
through my published module--how could I go about specifying that I want to
use JUnit 3.8.2 as opposed to 4.6, or vice versa? It doesn't seem that
dynamic revisions, in themselves, help me at this level.

On Thu, Jun 25, 2009 at 11:45 PM, Maarten Coene <>wrote:

> Maybe you could add replacedynamicrev="false" to your ivy:publish task?
> Maarten
> ----- Original Message ----
> From: Garima Bathla <>
> To:
> Sent: Friday, June 26, 2009 5:21:51 AM
> Subject: Ivy confs masquerading as dependencies' revisions
> Let's say I have an Ivy module that depends on JUnit. But when I go to
> publish version 1.0 of my module, I don't want to commit to a particular
> version of JUnit. I want to leave open the option to depend on either JUnit
> 3.8.2 or JUnit 4.6.
> The best way I've come up with to accomplish this is to create an Ivy conf
> for each JUnit version, so I would have dependencies like so:
>    <dependency org="org.junit" name="junit" rev="3.8.2"
> conf="junit-3.8.2->*" />
>    <dependency org="org.junit" name="junit" rev="4.6" conf="junit-4.6->*"
> />
> It strikes me as a bit hacky to be having Ivy confs masquerading as the
> revisions for a module's dependencies. I mean, the more revisions of that
> dependency you want to support in a single module, the more Ivy confs
> you're
> going to need. But then, I also understand that, when you go to publish a
> particular revision of an Ivy module, you're committing to not only that
> revision of that module but also to the revisions of its dependencies.
> I'm just wondering if there's a less cumbersome way to be flexible about
> the
> dependencies for a *published *Ivy module. But it seems like, logically,
> there *shouldn't* be.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message