ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goblirsch <dgoblir...@interactivebrokers.com>
Subject Re: artifactreport leaves out some dependencies
Date Sun, 28 Feb 2010 21:48:06 GMT
Maarten Coene wrote:
> Seems like a bug to me, could you provide more details?
>
> Maarten
>
>
> ----- Original Message ----
> From: David Goblirsch <dgoblirsch@interactivebrokers.com>
> To: ivy-user@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.


Mime
View raw message