Uploaded image for project: 'Ivy'
  1. Ivy
  2. IVY-1213

extends ignores defaultconfmapping/defaultconf/confmappingoverride attributes from parent's configurations and dependencies tags

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.2.0-RC1
    • 2.3.0-RC1
    • Core
    • None

    Description

      Using a parent ivy module with a configurations tag such as

      <ivy-module version="2.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
          <info
              organisation="com.foo"
              module="parent"
              status="integration" />
       	
      <configurations defaultconfmapping="compile->compile(*),master(*);runtime->runtime(*);test->runtime(*),master(*)">
              <conf name="default" visibility="public" description="runtime dependencies and master artifact can be used with this conf" extends="runtime,master"/>
              <conf name="master" visibility="public" description="contains only the artifact published by this module itself, with no transitive dependencies"/>
              <conf name="compile" visibility="public" description="this is the default scope, used if none is specified. Compile dependencies are available in all classpaths."/>
              <conf name="provided" visibility="public" description="this is much like compile, but indicates you expect the JDK or a container to provide it. It is only available on the compilation classpath, and is not transitive."/>
              <conf name="runtime" visibility="public" description="this scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath." extends="compile"/>
              <conf name="test" visibility="private" description="this scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases." extends="runtime"/>
              <conf name="system" visibility="public" description="this scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository."/>
              <conf name="sources" visibility="public" description="this configuration contains the source artifact of this module, if any."/>
              <conf name="javadoc" visibility="public" description="this configuration contains the javadoc artifact of this module, if any."/>
              <conf name="optional" visibility="public" description="contains all optional dependencies"/>
      </configurations>
      	<publications />
              <dependencies>
                  <dependency organisation="junit" module="junit" revision="4.8.2" conf="test" />
              </dependencies>
      </ivy-module>
      

      and later referring to that parent with an extends clause

      <ivy-module version="2.2"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      	xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
      	<info
      	   organisation="com.foo"
      	   module="module1"
      	   status="integration">
      	   <extends organisation="com.mysql.etools" module="etools-base" revision="1.0.0+" />
      	</info>
      
          <configurations />
      
          <publications><!-- omitted for brevity --></publications>
          <dependencies>
              <dependency organisation="com.google.collections" module="google-collections" revision="1.0" conf="compile" />
          </dependencies>
      </ivy-module>
      

      leads to the google-collections dependency not being retrieved, because the merged ivy module descriptor does not inherit the defaultconfmapping from its parent.
      Adding

      defaultconfmapping="compile->compile(*),master(*);runtime->runtime(*);test->runtime(*),master(*)"

      to the child module's configurations tags makes it work.
      Looking at XmlModuleDescriptorParser seems to support the fact that it does not merge tag attributes at all.

      Needless to say, this is really hard to find when refactoring modules to use extends.

      Attachments

        Activity

          People

            maartenc Maarten Coene
            kroepke Kay Röpke
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: