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: useOrigin and type filtering
Date Tue, 06 Mar 2007 13:11:20 GMT
On 3/6/07, Stephane Bailliez <sbailliez@gmail.com> wrote:
>
> I'm messing with useOrigin and the culprit is actually completely lost
> in getting me the correct artifacts when using cachepath.
> I have artifacts with different types for the same conf(ie: jar, source,
> javadoc) and while it works fine when doing a useOrigin=false with using
> useOrigin=true it manages to push me artifacts of type source instead of
> jar, so some filtering is going berserk somewhere.
>
> <ivy:resolve useorigin="${ivy.useorigin}" conf="*" showprogress="false"
> type="jar,javadoc,source"/>
> <ivy:cachepath useorigin="${ivy.useorigin}"
> pathid="ivy.compile.classpath" type="jar" conf="compile"/>
>
> I haven't yet investigated the problem, but ouf of curiosity, has anyone
> seeing this behavior before ?
> (ie: I'm using 1.4.1)


No, at least not yet :-)  And I'm surprised of this problem, because I see
no relation between the two. Except if the bug is that when using origin the
artifact type is lost... Strange.

Side note: there should be absolutely no need whatsoever to duplicate
> useorigin in every task once it has been resolved.

I agree it is weird, you can open an issue and relate it to scoping.

- Xavier

This is just a killer
> for modularity as if I want to enable this feature, I have to go through
> all build files that use retrieve to do some special packaging or
> layout. This information should be self contained in the resolution
> data. Scoping should hopefully help to get rid of this.
>
> -- stephane
>

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