On 6/12/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
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.
Nice
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.
Ok, I'll try to see what's going on.
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
This is a different type of conflict, it's only a retrieve conflict, which is not handled the same way as a resolve conflict. By using a different retrieve pattern (with revision or conf token), we wouldn't have any conflict. But nothing is mentioned about junit which is (according to the
report) present in the two confs.
If two different versions are selected in each conf we should have a retrieve conflict too. This requires investigation. Xavier --
Gilles SCOKART
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
