ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Gitman" <>
Subject Re: dealing with potentially redundant resolves & paths
Date Sat, 25 Oct 2008 16:04:21 GMT
So I delved a little more into the documentation for the *resolve *task:

And I came across the resolveId attribute and the various properties that
get set based on it--specifically the dynamic
ivy.resolved.configurations.${resolveId} property.

Below is my solution:
  <target name="resolve-compile" depends="...">
    <ivy:resolve file="ivy.xml" settingsRef="ivy.instance" *conf="${}"* *resolveId="${}"* />
    <ivy:cachepath pathid="classpath.dependencies.compile" conf="${}" type="jar" />

  <target name="resolve-runtime"
    <ivy:resolve file="ivy.xml" settingsRef="ivy.instance" conf="${}" resolveId="${}" />
    <ivy:cachepath pathid="classpath.dependencies.runtime" conf="${}" type="jar" />

First, in the target that does the compile ivy:resolve, I set the
resolveId attribute
on the first ivy:resolve to the placeholder that has the compile conf:

Then I only execute the target that does the runtime ivy:resolve if the
property ivy.resolved.configurations.${} has not
yet been set. If ${}=${},
then that property has indeed already been set and I skip the resolve.

If you look carefully at the second target, you might notice that I end up
having to depend on another target which, as suggested by its name, sets my
runtime dependencies classpath to the value of the compile dependencies
classpath in the case where I do want to reuse.

On Thu, Oct 23, 2008 at 10:10 PM, Mitch Gitman <> wrote:

> Gosh, I like to think I'm quite the Ivy expert, but I'm getting stumped by
> something pretty basic. I'm trying to avoid hard-coding the name of an Ivy
> configuration in my Ant build file when I do an ivy:resolve and an
> ivy:cachepath. Look at the "resolve-compile" target below for the property
> placeholder ${}:
>   <target name="resolve-compile" depends="…">
>     <ivy:resolve file="ivy.xml" settingsRef="ivy.instance" conf="*${
>}*" />
>     <ivy:cachepath pathid="classpath.dependencies.compile" conf="*${
>}*" type="jar" />
>   </target>
> Now, suppose that the placeholder ${} resolves
> to "default." Next, look at another target, "resolve-runtime," below for
> another property placeholder, ${}:
>   <target name="resolve-runtime" depends="…">
>     <ivy:resolve file="ivy.xml" settingsRef="ivy.instance" conf="*${
>}*" />
>     <ivy:cachepath pathid="classpath.dependencies.runtime" conf="*${
>}*" type="jar" />
>   </target>
> Suppose that second placeholder also resolves to "default." So you wind up
> with the equivalent of:
>   <target name="resolve-compile" depends="…">
>     <ivy:resolve file="ivy.xml" settingsRef="ivy.instance" conf="*default*"
> />
>     <ivy:cachepath pathid="classpath.dependencies.compile" conf="*default*"
> type="jar" />
>   </target>
>   <target name="resolve-runtime" depends="resolve-compile">
>     <ivy:resolve file="ivy.xml" settingsRef="ivy.instance" conf="*default*"
> />
>     <ivy:cachepath pathid="classpath.dependencies.runtime" conf="*default*"
> type="jar" />
>   </target>
> What I find when both these properties resolve to the same value is that,
> if "resolve-compile" gets executed before "resolve-runtime," the runtime
> path, as established by the cachepath pathid
> classpath.dependencies.runtime, fails to be established. It's like Ivy is
> ignoring this second cached path because it is already caching the same path
> under another name.
> Well, of course I'd like to know why this is happening.
> But beyond that, I notice that this ivy:resolve of a single conf in a
> single ivy.xml file gets executed twice: once for "resolve-compile," then
> again for "resolve-runtime." The second resolve really is redundant with
> the first one if the conf is the same. It's extra, unnecessary work.
> Sure, my Ant script could always check if the two confs are the same, and
> if they are, avoid the second resolve and just make the second classpath ref
> the same as the first. But that could get cumbersome fast if I'm dealing
> with numerous potentially identical confs that are specified as Ant
> properties. Is there some way for Ivy to preempt the second resolve?
> Or is there some other way I should be thinking about this problem?
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message