ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <>
Subject Re: blank branch
Date Mon, 18 Aug 2008 13:44:16 GMT

Hello Tom,

I am part of a build team which has a system in production with Ant 1.7
and Ivy (not the latest version, I think 2.0.0-alpha-1).

We manipulate branches only in setting files, not in ivy descriptors,
although this seems to be the right thing to do.

Our setting file says something like :

for our own artifacts, use branch=${ivy.branch}

this ivy.branch is an ant property which we set before invoking ivy

We are using ClearCase, and our trick is to have our ClearCase admin put
a comment in the view config specs, like #ivy.branch=4.2

A special ant task reads the ClearCase view config specs and sets
properties from them before invoking ivy configure.

Our ivy.xml files do not mention the fact that the home made artifacts
are branched.

If we ever need to use home made artifacts from several branches, we
would also define this in the settings file.



Tom Widmer wrote:
> I'm trying to set up a dependency system including branch support for
> our own artifacts. For the default branch, I'm not setting a branch
> attribute at all, nor is defaultBranch set in the settings. In a
> dependent module, I'm importing the dependency like this:
> <dependency org="xxx" name="yyy"
>                     branch="${yyy.branch}"
>                     rev="${}"
>                     conf="build->default"/>
> As you can see, I'm using an ant property to specify the branch.
> If I set the branch to the empty string "" in an attempt to get the
> default branch, the ivy:retrieve works fine the first time, when it
> has to populate the cache. However, when running it the second time
> (when the desired rev and all dependent revs are in the cache), it
> fails to resolve properly and instead outputs a series of ivy internal
> errors, such as:
>     ivy internal error: no node found for yyy#xxx;rev.20454: looked in
> [yyy#zzz;working@PC-WIDMER-T, yyy#xxx;rev.20454, com.sun#jre;1.6.0_05,
> com.sun#jce-policy;6,;9.0c,
> bouncycastle#bcprov-jdk16;136, commons-cli#commons-cli;1.1,
> commons-collections#commons-collections;3.2,
> commons-lang#commons-lang;2.3, commons-math#commons-math;1.1,
> commons-primitives#commons-primitives;1.0,
> net.sourceforge.collections#collections-generic;4.01,
> janino#janino;2.5.10, org.apache.xmlgraphics#batik-transcoder;1.7,
> com.jdatepicker#jdatepicker;4.2.5, com.sun.xml.bind#jaxb-impl;2.1.6,
> com.camcog#jniwrapper-mhs-cptII;1.0,
> com.camcog#jniwrapper-ms-word-2003;1.0,
> commons-logging#commons-logging;1.0.3,
> commons-discovery#commons-discovery;0.2,
> org.apache.xmlgraphics#fop;0.94,
> org.apache.xmlgraphics#batik-awt-util;1.7,
> org.apache.xmlgraphics#batik-bridge;1.7,
> org.apache.xmlgraphics#batik-dom;1.7,
> org.apache.xmlgraphics#batik-gvt;1.7,
> org.apache.xmlgraphics#batik-svg-dom;1.7,
> org.apache.xmlgraphics#batik-svggen;1.7,
> org.apache.xmlgraphics#batik-util;1.7,
> org.apache.xmlgraphics#batik-xml;1.7, xml-apis#xml-apis;1.3.04,
> xml-apis#xml-apis-ext;1.3.04,
> org.apache.xmlgraphics#xmlgraphics-commons;1.2,
> commons-logging#commons-logging;1.0.4, commons-io#commons-io;1.1,
> org.apache.avalon.framework#avalon-framework-api;4.3.1,
> org.apache.avalon.framework#avalon-framework-impl;4.3.1,
> org.apache.xmlgraphics#batik-anim;1.7,
> org.apache.xmlgraphics#batik-css;1.7,
> org.apache.xmlgraphics#batik-ext;1.7,
> org.apache.xmlgraphics#batik-parser;1.7,
> org.apache.xmlgraphics#batik-script;1.7, xalan#xalan;2.6.0,
> xml-apis#xml-apis;2.0.2, org.apache.xmlgraphics#batik-js;1.7,
> javax.xml.bind#jaxb-api;2.1,;1.0-2,
> javax.activation#activation;1.1, com.jniwrapper#jniwrap;2.9.5] and
> root module id was yyy#zzz;working@PC-WIDMER-T
> It then proceeds to evict most of my dependencies, apparently keeping
> the direct artifacts of the xxx, and apparently transitive
> dependencies 1 step removed, but the direct dependencies of xxx are
> not retrieved.
> Strangely, adding defaultBranch="" to my settings seems to fix the
> problem. Any idea what the problem is, and whether my solution is ok?
> I would have thought that an empty string branch and an unset branch
> should be treated the same.
> Thanks,
> Tom

View raw message