ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: The wrong jar gets retrieved
Date Mon, 16 Jul 2007 09:46:37 GMT
On 7/14/07, Jing Xue <jingxue@digizenstudio.com> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message