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

Incorrect retrieve for repository module which depends on a default and classifier artifact of another module

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

      Description

      Problem seen when retrieving gwt-user;2.5.1 from maven central

      The POM for that module contains

      <dependencies>
        <dependency>
          <groupId>javax.validation</groupId>
          <artifactId>validation-api</artifactId>
          <version>1.0.0.GA</version>
        </dependency>
        <dependency>
          <groupId>javax.validation</groupId>
          <artifactId>validation-api</artifactId>
          <version>1.0.0.GA</version>
          <classifier>sources</classifier>
        </dependency>
      </dependencies>
      

      The ivy.xml that gets derived from this an used in the cache contains

      <dependencies>
        <dependency org="javax.validation" name="validation-api" rev="1.0.0.GA" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
        <dependency org="javax.validation" name="validation-api" rev="1.0.0.GA" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)">
          <artifact name="validation-api" type="jar" ext="jar" conf="" m:classifier="sources"/>
        </dependency>
      </dependencies>
      

      But when I retrieve for my module which depends on gwt-user, I only get the -sources.jar for this transitive dependencies retrieved. According to the ivy:report, this dependency looks like

      <module organisation="javax.validation" name="validation-api">
        <revision name="1.0.0.GA" status="release" pubdate="20140804102902" resolver="NexusRepository" artresolver="NexusRepository" homepage="" downloaded="false" searched="false" default="false" conf="default, compile, master(*), compile(*), runtime, runtime(*), master" position="7">
          <license name="Apache License, Version 2.0" url="license.txt"/>
          <caller organisation="com.google.gwt" name="gwt-user" conf="default, compile, runtime, master" rev="1.0.0.GA" rev-constraint-default="1.0.0.GA" rev-constraint-dynamic="1.0.0.GA" callerrev="2.5.1"/>
          <artifacts>
            <artifact name="validation-api" type="jar" ext="jar" extra-classifier="sources" status="no" details="" size="65220" time="0" location="/x/eng/rtpbld00/scratch/dholmes/p4/ocf-nexus/ivy/cache/javax.validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar">
              <origin-location is-local="false" location="http://black-velvet.gdl.englab.netapp.com:8081/nexus/content/repositories/Unofficial/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar"/>
            </artifact>
          </artifacts>
        </revision>
      </module>
      

      What appears to have occurred is that the binary artifact which is implicitly specified by the first dependency in the derived ivy.xml file is 'lost' when the source specific artifact is added by the second dependency. Since there is now an actual list of artifacts for the module, that set (now only the sources one) is the only one retrieved.

      I'm thinking there are probably a couple possible solutions. One could be to explicitly add the artifacts to the derived ivy.xml files. Another could be to add the binary artifact explicitly during the resolve process in the case where the implicit specification would be lost because additional artifacts are selected.

      As a test, I modified the ivy.xml in my cache to the following and I did get both artifacts retrieved.

      <dependencies>
        <dependency org="javax.validation" name="validation-api" rev="1.0.0.GA" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)">
          <artifact name="validation-api" type="jar" ext="jar" conf=""/>
          <artifact name="validation-api" type="jar" ext="jar" conf="" m:classifier="sources"/>
        </dependency>
      </dependencies>
      

      I believe that I can work around this from my module that specifies gwt-user by explicitly including these transitive artifacts for the time being.

        Attachments

        Issue Links

          Activity

            People

            • Assignee:
              jaikiran Jaikiran Pai
              Reporter:
              netappbluedevil Daniel Holmes

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment