2007/6/11, Xavier Hanin <[EMAIL PROTECTED]>:
On 6/11/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>
> I made different test with the ivy.xml of ivy itself and I found
> unexpected behaviours. As I'm not sure if it is bugs or features, I
> preffer to discuss before raising an issue ;-)
>
>
> 1. I didn't see in the report that commons-httpclient 2.0 as been
> evicted. I only see the 3.0 version. However, commons-httpclient 2.0
> is a depdnecny of commons-vfs. Is it normal?
No, it doesn't seem normal. This is really strange since only the dependency
on commons-httpclient does not appear. It's maybe related to the namespace
used for commons-vfs.
I will raise an issue to keep track of that.
2. I have seen that some of our dependencies put junit into their
> dependencies without specifying the test scope. The make us depends on
> junit in our default scope as well. I tried to add an exclude under the
> dependency commons-httpclient and commons-cli but junit is still present
> present.
How did you exclude junit? Could you post your exact exclusion element? BTW,
for exclusion in the whole module, you can use module wide exclude instead
of excluding in httpclient and cli:
https://issues.apache.org/jira/browse/IVY-431
Maybe you could give me your opinion on this issue, the more I think about
it the more I'd prefer changing the syntax (see my last comment on the
issue).
I put the exclude under the dependency. I commited the change in svn.
See also the issue for my comment.
3. When I retrieve the confs default and test after my changes, there is
> a trace saying that commons-lang had a conflict in the two confs. But
> it didn't say that junit had a conflict (junit 3.8.1 is the dependency
> in the conf 'default' while 3.8.2 is the dependency in the conf 'test'.
Configurations are resolved individually, so Ivy does not consider this as a
conflict. Changing this behavior is not easy and risky, because it was quite
hard to make configurations independent (without actually running resolve
independently for each), so adding a setting to say if we want conflict
resolution to span over configurations would be difficult to implement I
think. Moreover, it would break some assertions, like resolve 'default' +
resolve 'test' <=> resolve 'default,test'. So the best we could do (IMO) is
to provide a log message, or a specific report.
There is actually a conflict resolution cross-config. I just commit a
new ivy.xml for ivy where you can see it.
At the end of a resolve, you have a trace :
[ivy:retrieve] :: retrieving :: [ apache | ivy ]
[ivy:retrieve] confs: [default, test]
[ivy:retrieve] conflict on c:\Documents and
Settings\gscokart\private\ivy\lib\commons-lang.jar in [test, default]:
2.3
But nothing is mentioned about junit which is (according to the
report) present in the two confs.
--
Gilles SCOKART
