Maarten Coene wrote:
Seems like a bug to me, could you provide more details?

Maarten




----- Original Message ----
From: David Goblirsch <dgoblir...@interactivebrokers.com>
To: ivy-u...@ant.apache.org
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!


SCENARIO
--------

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"
              rev="latest.integration"/>

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
reporting.


OBSERVED PROBLEM
----------------

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

 artifactreport-runtime.xml

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

  M-api.jar

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

  M-impl.jar

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
M-api.

  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"
              resolveMode="dynamic"
              />
 <ivy:retrieve conf="runtime"
     pattern="${ivy.lib.dir}/runtime/[artifact](-[revision]).[ext]"
               sync="true"
               />
 <ivy:report conf="runtime"
             graph="false"
             outputpattern="[module]-[conf].[ext]"
             todir="${dir.build}/report"
             />
 <ivy:artifactreport conf="runtime"
      tofile="${dir.build}/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
file.


DOES IT EVER WORK?
------------------

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.




Reply via email to