Setting ivy conflict managers

Question

I am trying to set conflict managers in Ivy, but I can't find a concrete example of how to set them. For example, to set the "strict" manager, what would this look like?

<conflict-managers>
  ???
</conflict-managers>

Answer 1

<rant>
Yeah, isn't Ivy documentation a hoot! I mean, does it have to be well organized and complete? Does it really have to make sense. I mean, it's not like my job depends upon it!

Wait a second, it does...
</rant>

Sorry, I have to get the state of Ivy documentation off my chest. It makes Maven documentation look wonderful in comparison.

The best book on Ivy I've found is Manning's Ant in Action. It's a seven year old book that's out of print (but is still available as an ebook. If it wasn't for this book, (which is using Ivy 1.4), I would have been completely lost. Unfortunately, it doesn't delve deep into the Ivy settings.

There is a listing of all of the possible conflict managers buried deep in the Ivy documentation.

• all this conflicts manager resolve conflicts by selecting all revisions. Also called the NoConflictManager, it doesn't evict any modules.
• latest-time this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
• latest-revision this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions.
• latest-compatible this conflict manager selects the latest version in the conflicts which can result in a compatible set of dependencies. This means that in the end, this conflict manager does not allow any conflicts (similar to the strict conflict manager), except that it follows a best effort strategy to try to find a set of compatible modules (according to the version constraints)
• strict this conflict manager throws an exception (i.e. causes a build failure) whenever a conflict is found.

I haven't played around with them, but I believe you simply do the following in the ivy-settings.xml:

<conflict-managers>
    <latest-revision/>
</conflict-managers>

You can also define conflict management in your ivy.xml too which might be a bit more practical since it can be defined on a module-by-module basis.

Of course a few examples would have gone a long way with this, but the Ivy documentation doesn't provide many.

Answer 2

The best book on Ivy I've found is Manning's Ant in Action.

That was me. Ivy has moved on a lot since then, and so have builds

One issue with the ivy conflict managers is that it differs from maven, whose policy is "shallowest on the graph first", that picks the closest one. This is good if you explicitly ask for a version, bad if you have >1 transitive dependency when "closest" isn't what you want.

With ivy you can hit the strict resolve which says "you have to explicitly resolve every single conflict in your dependencies". This adds extra work @ build time, but has a key result: if you explicitly declare the versions of things you want, you are now in control of what you have in your classpath.

Answer 3

The Ivy reference documentation strictly follows the XML tag structure of the ivy.xml and ivy-settings.xml files. You are expected to extract the information required directly from the document structure.

Decoding from the Ivy docs: The conflict-managers tag is for declaring what conflict managers a project may use and configuring them if they accept configuration, not for setting the conflict manager to use.

<conflict-managers>
    <latest-cm name="mylatest-conflict-manager" latest="my-latest-strategy"/>
    <compatible-cm name="my-latest-compatible-conflict-manager" latest="my-latest-strategy"/>

</conflict-managers>

The settings tag has an attribute for choosing the default conflict manager:

<settings defaultConflictManager="strict"/>

Or in an ivy.xml:

<dependencies>
    <dependency.../>
    <conflict manager="strict">
</dependencies>

Note that most of the conflict managers are more liberal in their interpretation of your intentions than you would expect. Two examples: * Branches are considered irrelevant, if a dependency is available on two branches the "latest" family of resolvers will pick the latest available from either. * Both the "latest-time" and "latest-revision" resolvers ignore version constraints except to set boundaries on the matching space. e.g. if a depends on b-1.0 and c-1.0 but c-1.0 depends on b-5.0 then you will get b-5.0 despite it not meeting the constraint requested. I assume your need is result of discovering one of these design flaws.