ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goblirsch <>
Subject Re: artifactreport leaves out some dependencies
Date Sun, 28 Feb 2010 21:54:47 GMT
Maarten Coene wrote:
> Seems like a bug to me, could you provide more details?
> Maarten
> ----- Original Message ----
> From: David Goblirsch <>
> To:
> Sent: Thu, February 25, 2010 7:18:33 PM
> Subject: artifactreport leaves out some dependencies
> I have a resolve target in an ant build that correctly finds all the jars;
> I can see them in build/lib/[conf].
> But my artifactreport-[conf].xml does not include a list of all the jars that
> the resolver found and in fact retrieved.
> Is this a bug, or does artifactreport "filter" the resolved list. If so, what
> is the "filter"?

I am sorry that I cannot just hand you a working example that
duplicates the bug, but the build involves proprietary jars and a
build system that is behind a corporate firewall.  So for now I will
have to provide a detailed description of the conditions under which
ivy:artifactreport fails to include some dependencies. Hopefully this
is enough to diagnose the problem!


I have 3 jars,

  P.jar         a project jar that contains a "main" program as well
                as other code.

  M-api.jar     a module api jar

  M-impl.jar    a module implementation jar.

In all 3 cases, the ivy files define 4 configurations:

   (+) api      which is extended by
   (-) compile  which is extended by
   (+) runtime  which is extended by
   (-) test

and the defaultconfmapping is set to

    "api->api, compile->api, runtime->runtime, test->runtime"

with confmappingoverride="true".

Because P.jar contains a "main" program, its build process ends with a
resolution of the "runtime" configuration.

For M-impl.jar, we have

   <dependency conf="compile" org="xxx" name="M-api"

For P.jar we have

   <dependency conf="compile" org="xxx" name="M-api"
               rev="latest.integration" />
   <dependency conf="compile" org="xxx" name="M-impl"
               rev="latest.integration" />

Since we use confmappingoverride="true" and since "runtime" extends
"compile", both M-api.jar and M-impl.jar should be found during the
"runtime" resolve.  They are (yeah!), but the problem is in the


The observed problem is this: When the local repository and local
cache are completely empty, i.e., there are no files under
~/.ivy2/cache or ~/.ivy2/local, then when a fresh build of P.jar is
complete, the file


contains an entry for M-impl, but NOT M-api.

Of course, for this build to even work, both M-api.jar and M-impl.jar
and their associated resolved ivy files are already published to a
"public" (within the company) repository.  We do not use version
numbers on our home-grown jars, so the published ivy file for


lists its revision as 20100218185041, and the published ivy file for


lists its revision as 20100218185204, claiming it was resolved against
version 20100218185043 of M-api.jar.  The build correctly finds and
"downloads" these jars from the "public" repository, but the
artifactreport for the "runtime" configuration is missing an entry for

   Possible clue: Note that the resolved version of M-api.jar
   in the M-impl ivy file is 2 seconds after the revision
   listed in the published M-api ivy file. However this may not be
   relevant since we do resolves with resolveMode="dynamic".

Note that our resolves are done with resolveMode="dynamic".  Here is
the runtime resolution chunk from the ant build file:

  <ivy:resolve conf="runtime"
  <ivy:retrieve conf="runtime"
  <ivy:report conf="runtime"
  <ivy:artifactreport conf="runtime"
       tofile="${}/report/artifactreport-runtime.xml" />

As mentioned above, both M-api.jar and M-impl.jar are placed into
build/lib/runtime, so the resolving part works beautifully.

Interestingly, the ivy:artifactreport issues a log message saying that
it sees M-api.jar; it just doesn't include it in the final report.
 From the build log (names replaced):

  [ivy:artifactreport]  found xxx#M-api;20100218185041 in production
  [ivy:artifactreport]  [20100218185041] xxx#M-api;latest.integration
  [ivy:artifactreport]  found xxx#M-impl;20100218185204 in production
  [ivy:artifactreport]  [20100218185204] xxx#M-impl;latest.integration

So ivy:artifactreport sees the dependency on M-api, logs that it found
it, but the element is MISSING from the artifactreport-runtime.xml


Yes.  If I now go and build a new version of M-api.jar locally, so
that is it published to the local repository, then when I rebuild
P.jar, M-api will be included in the report as expected.

View raw message