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 <[email protected]> To: [email protected] 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 <[email protected]> > To: [email protected] > 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.
