Maarten Coene wrote:
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
As I mentioned in a past email, when I add the <modules> element you
suggested, all other conditions the same,
the dependencies show up in the report as desired.
My next question is: Is this failure of artifactreport to just use the
results of the preceding resolve a bug?
Is the <modules/> suggestion above a "work around" for something that
will be fixed, or is that the expected thing to do?
----- 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.
