ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 15:50:43 GMT
On Wed, Feb 27, 2008 at 4:03 PM, Harald Braumann <> wrote:

> On Wed, 27 Feb 2008 14:23:50 +0100
> "Xavier Hanin" <> wrote:
> > On Wed, Feb 27, 2008 at 11:53 AM, Harald Braumann <>
> > wrote:
> >
> > > On Wed, 27 Feb 2008 10:27:04 +0100
> > > "Xavier Hanin" <> wrote:
> > >
> > > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
> > > > <> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > is it possible with ivy to specify the versions of dependencies
> > > > > separate from the actual dependency specification? Similar to
> > > > > the <dependencyMangement> section in maven's parent pom?
> > > >
> > > > There is no direct support for this currently in Ivy, what we
> > > > usually suggest is to use properties to specify the revisions,
> > > > and define these properties in a separate file. The result is
> > > > very similar to the dependency management feature.
> > >
> > > Fair enough, but like this I can only control direct dependencies.
> > > Maybe I should elaborate a bit more about what I want. Please note
> > > that I'm only familiar with Maven and only recently started to look
> > > into Ivy because I'm not completely satisfied with the former. So I
> > > might get the terminology wrong.
> > >
> > > Consider a project that is made up of multiple independent modules.
> > > Then there exists some uber-build, that has all the modules as
> > > dependencies and creates an installation package for the whole
> > > project.
> > >
> > > Many of the dependencies will be present in multiple modules, either
> > > directly or indirectly and very often with different versions. If I
> > > want to update some dependency, I don't want to go through all my
> > > modules and update there but I want to do it in a central place, for
> > > both direct and indirect dependencies.
> >
> > You can control indirect dependencies in conflict by using the
> > conflict management section of your ivy file. But this work only with
> > revisions in conflict. So there's currently no way in Ivy to override
> > the version of a dependency which is not in conflict and on which
> > your module does not depend. I didn't know that was possible with
> > maven2:
> The semantics of the dependencyManagement section was changed in
> 2.0.6 so that it can also override transitive dependencies [1].

That's probably why I wasn't aware of this.

> > the dependencyManagement documentation is not clear on this
> > subject.
> Well, documentation is one the points why I'm not really satisfied with
> Maven. But in this case I have to jump to maven's defence: "In addition,
> the version and scope of artifacts which are incorporated from
> transitive dependencies may also be controlled by specifying them in a
> dependency management section." [2]

You're right, this is clear enough. This documentation has been improved
since I last read it, this is a good point for maven users and for us too
(it helps to make Ivy compatible). I was refering to the documentation here:

where the sentence "this allows project authors to directly specify the
versions of artifacts to be used when they are encountered in transitive
dependencies or in dependencies where no version has been specified" can be
interpreted in two ways depending if you consider that  "where no version
has been specified" applies to direct dependencies only, or both transitive
and direct dependencies. But now I have a clear answer, both from the POM
reference doc and from experimentation.

BTW, I think that changing the dependency resolution algorithm in a
2.0.xrelease is pretty strange. This can easily break builds, which I
suspect when upgrading on a 2.0.x stream.

> > But now that I better see what is possible in maven, we can
> > consider that this is an incompatibility we have with maven2, and a
> > missing feature in terms of dependency management flexibility (no
> > alternative way to do it as I thought we had with properties). So we
> > should find a way to implement this for Ivy 2.0 final.
> Maybe similar to a virtual module? It could then be specified by
> org/name/etc. just like dependencies.

What do you mean by similar to a virtual module? Virtual module in Ivy has a
specific sense: it's a module which doesn't publish any artifact. But maybe
you're not referencing to this concept.

Personnally I was just thinking about something very similar to maven
dependency management feature, with slight adaptation to Ivy syntax.

Something like:
<ivy-module version="2.0">
  <info ... />
    <dependency org="foo" name="bar" rev="1.0"  />

Maybe we could allow to have wildcards in organization or module names,
using a matcher attribute to specify which matcher to use:
    <dependency org="foo" name="bar-*" rev="1.0" matcher="glob"  />

> > Could you open an issue about that?
> Well, I could, but I'm not sure if I'm the right person to do so. As I
> said, I don't know ivy that well, yet, and so I might not be able to
> express myself properly. Also, what I've noticed about maven is, that
> someone said "hey, this would be a cool feature" and then it was
> implemented without having a broader concept behind. And so the way
> dependencies are resolved changed in subtle ways from version to
> version. I wouldn't want to be the culprit for this to happen in ivy.
> I'm currently in the process of setting up a project using ivy so in
> the course of the next view days I should get a better understanding of
> ivy's concepts. I will come back to this issue.
> Of course I can also open an issue now so it won't be forgotten, if so
> desired.

Opening the issue now does not require much understanding of Ivy concepts.
Since Ivy is supposed to be compatible with maven2, you can first open a
simple bug stating that Ivy does not support dependencyManagement feature of
maven2 with transitive dependencies. Then later you (or somebody else) can
open an issue about how we could provide a similar feature in Ivy files, and
link the two issues. Issues are editable, commentable and a very good way to
track what should/can be done. And when you open an issue, it's easier for
us to track that someone in the community asked for it, rather than thinking
it's something that comes out of the committer team. And don't worry, you
will never be culprit of anything, it's our "job" as Ivy committers to make
sure things are implemented with whole consistency in mind. Well, it's what
we try to do at least :-)


> harry
> [1]
> [2]

Xavier Hanin - Independent Java Consultant

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