ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garima Bathla <garima.bat...@gmail.com>
Subject Re: Ivy confs masquerading as dependencies' revisions
Date Fri, 26 Jun 2009 19:42:22 GMT
Archie, thanks for taking a stab at this. Let's follow the example of Foo
depending on Bar depending on JUnit.

And let's follow your suggestion and put the dependency on JUnit directly in
Foo's ivy.xml:
    <dependency org="org.junit" name="junit" rev="3.8.2" conf="..."
/>

Now, the question arises, what to do about Bar's dependency on JUnit?
Suppose I keep it there:
    <dependency org="org.junit" name="junit" rev="[3.8.2,4.6]" conf="..." />

Having this dependency there in Bar actually causes Ivy to ignore Foo's
request for JUnit 3.8.2. Instead, JUnit 4.6 is what gets resolved.

Now, if I remove this dependency from Bar's ivy.xml, the resolve for Foo
will work and I'll get JUnit 3.8.2.

One could ask, why do you even want the dependency on JUnit in Bar's ivy.xml
anyway? Isn't it academic since you're going to have to be specifying the
need for JUnit up in Foo's ivy.xml anyway? And I don't dispute this
observation.

But the implication here is, if you want to control the revisions of
your *indirect
*Ivy dependencies--well, actually you can't. What you have to do is bubble
them up to the surface and make them *direct *Ivy dependencies. Now, it's a
fair argument that this is still probably the lesser evil compared to
creating special "junit-3.8.2" and "junit-4.6" Ivy confs in the Bar Ivy
module. But I wish there were a way to make Ivy more dynamic or lazy about
how it does resolves and publishes.

On Fri, Jun 26, 2009 at 8:43 AM, Archie Cobbs <archie.cobbs@gmail.com>wrote:

> Suppose FOO is your module that depends on the intermediate module BAR, and
> BAR is the module that depends loosely (i.e., will accept either version)
> on
> junit.
>
> If FOO only works with 3.8.2, then the solution is to just include a strict
> dependency on junit 3.8.2 in FOO's ivy.xml.
>
> -Archie
>
> On Fri, Jun 26, 2009 at 10:28 AM, Garima Bathla <garima.bathla@gmail.com
> >wrote:
>
> > 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 <maarten_coene@yahoo.com
> > >wrote:
> >
> > >
> > > Maybe you could add replacedynamicrev="false" to your ivy:publish task?
> > > http://ant.apache.org/ivy/history/2.1.0-rc1/use/publish.html
> > >
> > > Maarten
> > >
> > >
> > >
> > >
> > > ----- Original Message ----
> > > From: Garima Bathla <garima.bathla@gmail.com>
> > > To: ivy-user@ant.apache.org
> > > 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.
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Archie L. Cobbs
>

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