Ivy
  1. Ivy
  2. IVY-983

exclude does not work in non-trivial conf case

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0-RC2
    • Fix Version/s: 2.1.0-RC2
    • Component/s: None
    • Labels:
      None
    • Environment:

      Ubuntu, Linux

      Description

      I'm running into a problem with <exclude>... my ivy.xml looks like this:

      <ivy-module version="2.0">
      <info organisation="ssn-src" module="pc"/>
      <configurations defaultconfmapping="default->default">
      <conf name="default" />
      <conf name="provided" description="they are provided by the env." />
      <conf name="compile" extends="default,provided" />
      <conf name="war" extends="default"/>
      </configurations>
      <dependencies>
      ...
      <dependency org="log4j" name="log4j" rev="1.2.14+"
      conf="provided->default"/>
      ... <!-- other deps; indirect depends on log4j 1.2.13 in all my confs. -->
      <exclude module="log4j" conf="war"/>

      Now, log4j;1.2.14 is in my compile conf, as I expect it to be. But
      log4j;1.2.13 appears in my war conf, which is not what I expect. I expect
      there to be no log4j because in this case the environment will provide it
      (jboss) with its own custom.

        Issue Links

          Activity

          Hide
          Benjamin Damm added a comment -

          Increasing priority; our workaround scenarios are quickly getting out of hand.

          Show
          Benjamin Damm added a comment - Increasing priority; our workaround scenarios are quickly getting out of hand.
          Hide
          Daniel Dekany added a comment -

          In my experience <exclude> simply doesn't work at all if there is a "conf" attribute. If I omit that, it suddenly works. It's like if the conf never matches... or maybe I misunderstand the meaning of that parameter. It's an Ivy 2.0.0 final here.

          Show
          Daniel Dekany added a comment - In my experience <exclude> simply doesn't work at all if there is a "conf" attribute. If I omit that, it suddenly works. It's like if the conf never matches... or maybe I misunderstand the meaning of that parameter. It's an Ivy 2.0.0 final here.
          Hide
          Jason Porter added a comment -

          The root of this issue (at least from my debugging and testing) stems from the dependency only belonging to one configuration. In the example by Benjamin log4j is only assigned to the provided scope. It's included in compile and war because they extend provided but it is not actually in those configurations. If you were to debug it and look at the DependencyDescriptor it would say this (toString): log4j#log4j;1.2.14

          {provided=[default]}

          . I think what we'd expect it to say is this: log4j#log4j;1.2.14

          {provided=[default], compile=[default]}

          . In this example: log4j#log4j:1.2.13

          {default=[default]}

          or

          {compile=[<something, can't tell>]}

          which is why you can't exclude it from the war config, because it isn't even in there.

          Either we need to traverse the configuration graph and add each configuration where it appears (include extensions) or the exclude needs to traverse the graph looking at every configuration that makes up the one listed in the conf attribute. Sorry if that wasn't very coherent

          Show
          Jason Porter added a comment - The root of this issue (at least from my debugging and testing) stems from the dependency only belonging to one configuration. In the example by Benjamin log4j is only assigned to the provided scope. It's included in compile and war because they extend provided but it is not actually in those configurations. If you were to debug it and look at the DependencyDescriptor it would say this (toString): log4j#log4j;1.2.14 {provided=[default]} . I think what we'd expect it to say is this: log4j#log4j;1.2.14 {provided=[default], compile=[default]} . In this example: log4j#log4j:1.2.13 {default=[default]} or {compile=[<something, can't tell>]} which is why you can't exclude it from the war config, because it isn't even in there. Either we need to traverse the configuration graph and add each configuration where it appears (include extensions) or the exclude needs to traverse the graph looking at every configuration that makes up the one listed in the conf attribute. Sorry if that wasn't very coherent
          Hide
          Nicolas Lalevée added a comment -

          I have been able to reproduce the bug with a unit test and I fixed the bug.

          Show
          Nicolas Lalevée added a comment - I have been able to reproduce the bug with a unit test and I fixed the bug.
          Hide
          Matt Goldspink added a comment -

          I'm not sure this is fixed in 2.1.0-rc2 or perhaps not for the use case I'm looking for.

          I have an Ivy file like:

          <ivy-module version="1.0">

          <info organisation="matt" module="project2" revision="1.0.0"/>

          <configurations>
          <conf name="war-runtime"/>
          <conf name="build-war" extends="war-runtime" visibility="private"/>
          </configurations>

          <dependencies>
          <dependency org="matt" name="project1" rev="1.0" conf="war-runtime"/>

          <exclude org="javax.servlet" module="servlet-api" conf="war-runtime" />

          </dependencies>

          </ivy-module>

          In this case project1 depends on the servlet-api dependency and transitively brings it into project2. Now I want it to be excluded from my war-runtime but to be present on the build-war configuration. However the above configuration seems to still bring down servlet-api. I've tried various combinations of the above including explicitly declaring the dependency in this file as build-war dependency, specifying the artifact name etc, but none seem to give me what I want. Should this be re-opened or another JIRA filed?

          Show
          Matt Goldspink added a comment - I'm not sure this is fixed in 2.1.0-rc2 or perhaps not for the use case I'm looking for. I have an Ivy file like: <ivy-module version="1.0"> <info organisation="matt" module="project2" revision="1.0.0"/> <configurations> <conf name="war-runtime"/> <conf name="build-war" extends="war-runtime" visibility="private"/> </configurations> <dependencies> <dependency org="matt" name="project1" rev="1.0" conf="war-runtime"/> <exclude org="javax.servlet" module="servlet-api" conf="war-runtime" /> </dependencies> </ivy-module> In this case project1 depends on the servlet-api dependency and transitively brings it into project2. Now I want it to be excluded from my war-runtime but to be present on the build-war configuration. However the above configuration seems to still bring down servlet-api. I've tried various combinations of the above including explicitly declaring the dependency in this file as build-war dependency, specifying the artifact name etc, but none seem to give me what I want. Should this be re-opened or another JIRA filed?
          Hide
          stan towianski added a comment -

          my ivy.xml file (parts):

          <conf name="default" description="default"/>
          <conf name="provided" description="used to specify that jar is already provided within environment"/>
          <conf name="runtime" description="used for runtime"/>
          <conf name="test" visibility="private" description="used for testing"/>

          <dependency org="org.apache" name="log4j" rev="1.2.16" conf="provided->default">
          <exclude module="jmxtools"/> <- these 2 don't matter
          <exclude module="jmxri"/>
          </dependency>

          <exclude module="log4j" conf="runtime"/>
          or
          <exclude org="org.apache" module="log4j" conf="runtime"/>

          <exclude module="log4j"/> <-- keeps it out of 'provide', but it still showed up in 'runtime'

          These 2 still pull down log4j-1.2.16.jar into libDir\runtime

          <ivy:resolve file="ivy.xml" conf="runtime" />
          <ivy:retrieve file="ivy.xml" conf="runtime" pattern="$

          {libDir}

          /[conf]/[artifact]-[revision].[ext]" />

          [ivy:resolve] :: Ivy 2.1.0 - 20090925235825 :: http://ant.apache.org/ivy/ ::

          This bug stills seems to be there.

          Show
          stan towianski added a comment - my ivy.xml file (parts): <conf name="default" description="default"/> <conf name="provided" description="used to specify that jar is already provided within environment"/> <conf name="runtime" description="used for runtime"/> <conf name="test" visibility="private" description="used for testing"/> <dependency org="org.apache" name="log4j" rev="1.2.16" conf="provided->default"> <exclude module="jmxtools"/> <- these 2 don't matter <exclude module="jmxri"/> </dependency> <exclude module="log4j" conf="runtime"/> or <exclude org="org.apache" module="log4j" conf="runtime"/> <exclude module="log4j"/> <-- keeps it out of 'provide', but it still showed up in 'runtime' These 2 still pull down log4j-1.2.16.jar into libDir\runtime <ivy:resolve file="ivy.xml" conf="runtime" /> <ivy:retrieve file="ivy.xml" conf="runtime" pattern="$ {libDir} / [conf] / [artifact] - [revision] . [ext] " /> [ivy:resolve] :: Ivy 2.1.0 - 20090925235825 :: http://ant.apache.org/ivy/ :: This bug stills seems to be there.
          Hide
          stan towianski added a comment -

          We wonder if this bug is tied to log4j in particular because when we do a parallel
          set up with org.apache#xml-api it works just like we want it to!
          It pulls it into the 'provide' lib and does not in 'runtime'.

          Show
          stan towianski added a comment - We wonder if this bug is tied to log4j in particular because when we do a parallel set up with org.apache#xml-api it works just like we want it to! It pulls it into the 'provide' lib and does not in 'runtime'.
          Hide
          stan towianski added a comment -

          The bug is there for org.apache#commons.logging also.

          Show
          stan towianski added a comment - The bug is there for org.apache#commons.logging also.
          Hide
          stan towianski added a comment -

          One general thing we figured out is that if you have a circular dependency, excludes will not work.
          I do not know if that is for all excludes or not. If you have A depends on B, and B depends on C, and C depends on A,
          then we had excludes that did not work. When we fixed the circular dependency, the exclude started working,
          in this case for some apache-cxf -> geronimo_something jar.

          You can find circular dependencies with something like tattletale.jar

          I thought I read somewhere that excludes were supposed to happen last, though I did not find it just now,
          but there must be something in ivy in the case above that will keep excludes from working.

          This happened in ivy-2.1.0 and ivy-2.2.0

          Show
          stan towianski added a comment - One general thing we figured out is that if you have a circular dependency, excludes will not work. I do not know if that is for all excludes or not. If you have A depends on B, and B depends on C, and C depends on A, then we had excludes that did not work. When we fixed the circular dependency, the exclude started working, in this case for some apache-cxf -> geronimo_something jar. You can find circular dependencies with something like tattletale.jar I thought I read somewhere that excludes were supposed to happen last, though I did not find it just now, but there must be something in ivy in the case above that will keep excludes from working. This happened in ivy-2.1.0 and ivy-2.2.0
          Hide
          Maarten Coene added a comment -

          I'm reopening the issue so we don't forget to investigate this further...

          Show
          Maarten Coene added a comment - I'm reopening the issue so we don't forget to investigate this further...
          Hide
          Vadim Kopichenko added a comment -

          Please, also take a look at IVY-1443 with reproducible test case. May be related.

          Show
          Vadim Kopichenko added a comment - Please, also take a look at IVY-1443 with reproducible test case. May be related.

            People

            • Assignee:
              Unassigned
              Reporter:
              Benjamin Damm
            • Votes:
              6 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development