[
https://issues.apache.org/jira/browse/IVY-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437315#comment-13437315
]
Danny Yates commented on IVY-1371:
----------------------------------
Our real use-case on this has a defaultconfmapping of "%->default" (which we
neglected to test when reproducing, sorry) which should preclude the need for a
mapped attribute in most cases, no?
The real question here is, when trying to resolve the "transitive" conf, why
are dependencies that aren't even in that conf resolved? Especially given that
this appears to work fine when using the abridged form (a conf attribute with
';' separators). This suggests that it's just a parsing bug whereby the two
different syntaxes generate different state for the internal model.
See also my other bug report (1369) which is similar -- works using the
abridged from, doesn't work using the long form.
We're working on migrating an enterprise application which uses "all the open
source" in a giant unmanaged "lib" directory to Ivy. Our Ivy file is,
literally, hundreds of lines long. Having to add a mapped attribute to each
dependency is going to be painful!
Thanks,
Danny.
> Incorrect artifact resolution when using nested <conf> elements
> ---------------------------------------------------------------
>
> Key: IVY-1371
> URL: https://issues.apache.org/jira/browse/IVY-1371
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.0, 2.3.0-RC1
> Reporter: Danny Yates
> Attachments: build.xml, ivy.xml
>
>
> Please see attached build.xml and ivy.xml
> When resolving the 'transitive' conf, Ivy pulls down Mina, which is not in
> that conf, and it additionally pulls down Mina's transitive dependencies even
> though the conf that Mina is in has transitivity turned off.
> If you use the alternative "inline" syntax for conf mapping, this bug doesn't
> happen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
