Ivy
  1. Ivy
  2. IVY-1371

Incorrect artifact resolution when using nested <conf> elements

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0, 2.3.0-RC1
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      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.

      1. ivy.xml
        0.8 kB
        Danny Yates
      2. build.xml
        0.6 kB
        Danny Yates

        Activity

        Hide
        Danny Yates added a comment - - edited

        Thanks Maarten.

        My understanding was that breaking an inline conf mapping into <conf> elements was essentially the same as splitting on ';', and then getting the name and mapped attrs was the same as splitting on '->'. Does that make sense?

        So

        <dependency conf='a->b;c;d->e' ... />

        would be the same as

        <dependency ...>
        <conf name='a' mapped='b'/>
        <conf name='c'>
        <conf name='d' mapped='e'/>

        No?

        But in the former case the defaultconfmapping would get applied to conf 'c' but it wouldn't in the latter?

        It seems to me that the two syntaxes should be semantically identical. We use the latter because we have a lot of confs for building our code. But it does seem to behave logically - at least in my small brain!

        Thanks for your time on this.

        Show
        Danny Yates added a comment - - edited Thanks Maarten. My understanding was that breaking an inline conf mapping into <conf> elements was essentially the same as splitting on ';', and then getting the name and mapped attrs was the same as splitting on '->'. Does that make sense? So <dependency conf='a->b;c;d->e' ... /> would be the same as <dependency ...> <conf name='a' mapped='b'/> <conf name='c'> <conf name='d' mapped='e'/> No? But in the former case the defaultconfmapping would get applied to conf 'c' but it wouldn't in the latter? It seems to me that the two syntaxes should be semantically identical. We use the latter because we have a lot of confs for building our code. But it does seem to behave logically - at least in my small brain! Thanks for your time on this.
        Hide
        Maarten Coene added a comment -

        The documentation says that if no mapped attribute is specified, it will be mapped to the same configuration as specified with the name attribute. This doesn't seem to work, so this is a bug. A quick look at the parser shows me that in some cases (like yours), the <conf> element is completely ignored and your dependency will receive the '%->default' configuration, which could explain your observation. I think we can fix this bug in the 2.3.0 release.

        Beside this bug, you are requesting a new feature: if the mapped attribute isn't specified, the value of the defaultconfmapping attribute should be considered. This is a new feature request, which will probably not make it into the 2.3.0 release since we are already in the stage of release candidates which means we don't add new features anymore. In addition, this change of default value could break existing ivy files, so we have to think about this in more detail, although I agree that using the defaultconfmapping as default seems like a good idea.

        Show
        Maarten Coene added a comment - The documentation says that if no mapped attribute is specified, it will be mapped to the same configuration as specified with the name attribute. This doesn't seem to work, so this is a bug. A quick look at the parser shows me that in some cases (like yours), the <conf> element is completely ignored and your dependency will receive the '%->default' configuration, which could explain your observation. I think we can fix this bug in the 2.3.0 release. Beside this bug, you are requesting a new feature: if the mapped attribute isn't specified, the value of the defaultconfmapping attribute should be considered. This is a new feature request, which will probably not make it into the 2.3.0 release since we are already in the stage of release candidates which means we don't add new features anymore. In addition, this change of default value could break existing ivy files, so we have to think about this in more detail, although I agree that using the defaultconfmapping as default seems like a good idea.
        Hide
        Danny Yates added a comment -

        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.

        Show
        Danny Yates added a comment - 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.
        Hide
        Maarten Coene added a comment -

        ok, it seems a bug.
        You can also workaround it by providing a 'mapped' attribute:

        <dependency...>
        <conf name="transitive" mapped="default" />
        </dependency>

        You will have to use this 'mapped' attribute anyway, because if Ivy worked as documented on this, it would give the 'mapped' attribute a default value of 'transitive', so Ivy would try to resolve the 'transitive' configuration of 'spring-core' which doesn't exist.

        Show
        Maarten Coene added a comment - ok, it seems a bug. You can also workaround it by providing a 'mapped' attribute: <dependency...> <conf name="transitive" mapped="default" /> </dependency> You will have to use this 'mapped' attribute anyway, because if Ivy worked as documented on this, it would give the 'mapped' attribute a default value of 'transitive', so Ivy would try to resolve the 'transitive' configuration of 'spring-core' which doesn't exist.

          People

          • Assignee:
            Unassigned
            Reporter:
            Danny Yates
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development