ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Clitheroe <>
Subject Re: Question about documentation
Date Tue, 05 Oct 2010 20:50:22 GMT
This is excellent:

This has a very good chapter -  it's a little old (pre move to Apache) but
the concepts are the same.

This has a section in a chapter but I haven't read the book

This is far more Maven focused but well worth a read (your going to use
Maven repos a lot so understanding some of the approaches is worth it).

And, once you get the basics, then understanding configurations is really
important.  The issue here is that like most good open source projects Ivy
is trying to be really flexible as well as allow for other peoples

If you're using Eclipse then is worth it.
If you use netbeans then I can point you to our build base files that
bootstrap Ivy for you and give you all the basic features you need.

If I was starting now I would have a look at the SBT - it's aimed at Scala
but I can't see why it wouldn't work for dependency management for a Java
only project - think Ivy on rails.

And persevere, it's confusing at first but well worth it!


On Wed, Oct 6, 2010 at 6:55 AM, Steve Miller <> wrote:

> See below:
> On Tue, Oct 5, 2010 at 1:31 PM, David Sills <>
> wrote:
> > Alex:
> >
> > Thanks. That clarified a lot, as did actually going to the ivysettings
> > file, grabbing the pattern, and substituting the values for organization
> > and so forth from some of the dependencies in the ivy.xml file. The XML
> > that my browser grabbed made things a good deal clearer and I see your
> > point about the "->" operator.
> >
> > I would be happy to attempt to add something to the documentation that
> > could make this point considerably clearer, if I can figure out how to
> > use xooki.
> No need to understand it, just open the index.htm file from your
> filesystem, and the edit button will appear.
> It's not great, but it works.
> >
> > So, if I understand you correctly, the whole thing depends on the public
> > repositories maintaining their configuration structure? Essentially a
> > naming convention? It would be bad form to make too many deletions of
> > configurations. Or perhaps I missed your point?
> This problem is a dependency management issue, not specifically an Ivy
> issue. The convention that helps get around this is assuming that a
> published module will not change, unless it changes versions. So if
> you point to a specific version of commons-logging or something, the
> configurations will never change. If they do, then blame the
> publisher.
> >
> > And "default" being magic is also not perfectly obvious (merely quite
> > obvious), but OK, so it's magic.
> >
> > One more question. I can understand Ivy as being really, really useful
> > in two cases:
> >
> > 1. when your dependencies have transitive dependencies that you need to
> > grab
> > 2. when your dependency should be on some sort of dynamic version
> > ("")
> >
> > When you have but a single literal version of a JAR and that JAR has no
> > dependencies, what do you gain over simply getting the JAR file
> > yourself? (Other, of course, than consistency in build practices)
> If your project is simple, you don't need a DM tool. Once you do, yes,
> it's consistent.
> Two non-ivy specific advantages of dependency management I like are:
> 1) Since the artifacts are in a separate repository, you don't have to
> commit them in source control (if you don't want to, since a repo
> could be in a source control system).
> 2) You don't have to deal with copying jar files around, since you
> separate the WHAT from the WHERE. Your ivy-settings.xml file defines
> where repositories are. The ivy.xml file defines what dependencies you
> need. So when I want to use another library (that is already in my
> repo), I just modify the ivy.xml file and I get the dependency in my
> ant build and my IDE (with a plugin).
> >
> > Again, many thanks for your tolerance of what must seem silly questions,
> > but the answers are proving most enlightening.
> >
> > David Sills
> >
> >

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