ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Coene <maarten_co...@yahoo.com>
Subject Re: artifactreport leaves out some dependencies
Date Mon, 01 Mar 2010 22:08:59 GMT
It's hard to tell what's going wrong.
After looking at the code, I think the artifactreport does ignore the fact that the resolve
should be done in dynamic resolveMode.

Could you verify this hypothesis by setting the resolveMode to dynamic in your settings.xml?
Cfr http://ant.apache.org/ivy/history/latest-milestone/settings/module.html

<ivysettings>
    ...
    <modules>
        <module organisation="xxx" name="*" resolveMode="dynamic"/>
    </modules>
</ivysettings>

Where xxx is the organisation of your P module.

regards,
Maarten


----- Original Message ----
From: David Goblirsch <dgoblirsch@interactivebrokers.com>
To: ivy-user@ant.apache.org
Sent: Mon, March 1, 2010 3:46:02 PM
Subject: Re: artifactreport leaves out some dependencies

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