On 7/14/07, Jing Xue <[EMAIL PROTECTED]> wrote:
On Fri, Jul 13, 2007 at 10:51:43AM -0400, Jing Xue wrote: > > I'm running into a weird scenario where ivy retrieves the wrong jar > from a different module after resolving some conflicts. [snip] > > I suppose the questions I have would begin with where the conflicts > came from, and also how the aspectwerkz-core would get involved in the > retrieve of a different module, namely aspectwerkz/aspectwerkz-jdk5, > at all. I think I figured out at least part of the myth. Looks like there is one documentation issue _and_ a potential feature request: 1. The descriptions for 'organisation' and 'module' for post resolve tasks look as if they are merely optional but still effective for non-inline mode, while in fact under non-inline mode they are actually completely ignored, and ivy:retrieve always retrieves by the conf name.
No, org and module are not fully ignored, but they are used to reuse the result of a resolve made during a different build. I think you are not using them properly here: it should be the identifier of a root module you have resolved. But indeed I agree there is a documentation issue here, and maybe also an error report because I think the retrieve task should fail when used like you do. 2. If my take on 1 is correct, then looks like there isn't any way to
selectively retrieve one single artifact. The workaround I ended up making is defining a conf "aspectwerkz-jdk5", which includes only aspectwerkz.aspectwerkz-jdk5, and retrieving only that conf. It would be nice if 'organisation' and 'module' can be effective for selecting a module even under non-inline mode.
I'd better do that with include/exclude filters. I think there's already an issue in JIRA to have more flexible filters for some tasks (resolve, retrieve, cachepath, cachefileset at least). Indeed in your case you do a full resolve, and then want a very filtered retrieve. If you find the issue vote for it if you think it would fulfill your need, if you don't open another one. As a workaround using a dedicated configuration is a good solution. BTW, the conflicts problem you had were retrieve conflicts, which are different from resolve conflicts. During resolve Ivy find conflicts between modules in the whole graph, based on modules identifiers (org/name/branch/rev). During retrieve a conflict is found only when several artifacts lead to the same file after applying the pattern. In your case Ivy actually tried to retrieve all your dependencies to the same location (since your pattern wasn't using any token), therefore it thought there was a conflict between all your dependencies fighting for the same retrieve destination. HTH, Xavier Have a great weekend!
-- Jing Xue
-- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
