Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-2076

Artifact not found resolving dependencies with packaging/type "eclipse-plugin"

    Details

    • Type: Improvement
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: 0.8
    • Fix Version/s: 1.0-milestone-9
    • Gradle Forums topic Reference:

      Description

      I'm currently writing a JaCoCo gradle plugin and have a dependency on the JaCoCo modules. Unfortunately, the pom for the modules specifies that the jar files have packaging "eclipse-plugin". This appears to translate into a resolved dependency which, when printed, looks like:

      [[ResolvedArtifact dependency:org.jacoco:org.jacoco.agent:0.5.6.201201232323;default name:org.jacoco.agent classifier:null extension:eclipse-plugin type:eclipse-plugin]

      Dependency resolution then fails with:

      Could not resolve all dependencies for configuration ':services:agent:testRuntime'.
      Cause: Artifact 'org.jacoco:org.jacoco.agent:0.5.6.201201232323@eclipse-plugin' not found

      It seems that, because it is using Ivy under the covers, Gradle is falling victim to IVY-899 .

      An example pom from one of the JaCoCo modules:

      <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
      <modelVersion>4.0.0</modelVersion>
      <parent>
      <groupId>org.jacoco</groupId>
      <artifactId>org.jacoco.build</artifactId>
      <version>0.5.6.201201232323</version>
      <relativePath>../org.jacoco.build</relativePath>
      </parent>

      <artifactId>org.jacoco.report</artifactId>
      <packaging>eclipse-plugin</packaging>
      <name>JaCoCo :: Report</name>
      <description>JaCoCo Reporting</description>

      <dependencies>
      <dependency>
      <groupId>$

      {project.groupId}

      </groupId>
      <artifactId>org.jacoco.core</artifactId>
      </dependency>
      </dependencies>

      <build>
      <sourceDirectory>src</sourceDirectory>
      </build>
      </project>

      Is there a workaround available in Gradle (SBT has one for example)?

        Activity

        forums Gradle Forums created issue -
        Hide
        forums Gradle Forums added a comment -

        Your analysis is essentially correct: thanks for pointing out IVY-899. However due to changes required to the pom parsing code, we've already forked the ivy code involved, so we shouldn't need to wait for an ivy fix (we can do it ourselves).

        Currently, Gradle has special handling for "pom", "ejb", "bundle" and "maven-plugin"; otherwise we just map the "packaging" value to the extension of the main artifact. Do you have any documentation on what are the allowable packaging values in maven, and how they should be mapped? I can't find anything comprehensive.

        A possible workaround would be to use a "Client Module" to declare this dependency: [1]http://gradle.org/docs/current/usergu.... Gradle would then override the published metadata with the dependency metadata declared in your build script. This can be done on a per-dependency basis.
        ----------------------------------------------------------------------------------------
        [1] http://gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies

        Show
        forums Gradle Forums added a comment - Your analysis is essentially correct: thanks for pointing out IVY-899. However due to changes required to the pom parsing code, we've already forked the ivy code involved, so we shouldn't need to wait for an ivy fix (we can do it ourselves). Currently, Gradle has special handling for "pom", "ejb", "bundle" and "maven-plugin"; otherwise we just map the "packaging" value to the extension of the main artifact. Do you have any documentation on what are the allowable packaging values in maven, and how they should be mapped? I can't find anything comprehensive. A possible workaround would be to use a "Client Module" to declare this dependency: [1] http://gradle.org/docs/current/usergu.... Gradle would then override the published metadata with the dependency metadata declared in your build script. This can be done on a per-dependency basis. ---------------------------------------------------------------------------------------- [1] http://gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies
        daz Daz DeBoer made changes -
        Field Original Value New Value
        Assignee Daz DeBoer [ daz ]
        Fix Version/s 1.0-milestone-9 [ 10161 ]
        Affects Version/s 0.8 [ 10041 ]
        Priority Minor [ 4 ]
        Component/s dependencies [ 10022 ]
        daz Daz DeBoer made changes -
        Labels dependencies
        Hide
        daz Daz DeBoer added a comment -

        Maven pom modules with packing = 'eclipse-plugin' are now assumed to have 'jar' artifacts.

        Show
        daz Daz DeBoer added a comment - Maven pom modules with packing = 'eclipse-plugin' are now assumed to have 'jar' artifacts.
        daz Daz DeBoer made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        jptech Ryan J added a comment - - edited

        This is also a problem for Jetty. One of the artifacts uses orbit packaging with a jar extension.

        http://search.maven.org/#artifactdetails|org.eclipse.jetty.orbit|javax.servlet|3.0.0.v201112011016|orbit

        I think this is a mailing list post explaining what they're trying to accomplish, but it's long and I can't find a decent threaded version of the conversation.

        http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg02398.html

        This works for me (for now).

        compile module("org.eclipse.jetty:jetty-server:8.1.2.v20120308") {
            dependencies(
                "org.eclipse.jetty.orbit:javax.servlet:3.0.0.v201112011016@jar",
                "org.eclipse.jetty:jetty-continuation:8.1.2.v20120308",
                "org.eclipse.jetty:jetty-http:8.1.2.v20120308"
            )
        }
        

        There's also jbi-component and jbi-shared-library suggested in IVY-899.

        I might be wrong, but Maven seems to default to jar if <type></type> isn't specified in the dependency declaration. Would defaulting to jar for unknown packaging types cause problems with Gradle (or Ivy for that matter)?

        Edit: JETTY-1493

        Show
        jptech Ryan J added a comment - - edited This is also a problem for Jetty. One of the artifacts uses orbit packaging with a jar extension. http://search.maven.org/#artifactdetails |org.eclipse.jetty.orbit|javax.servlet|3.0.0.v201112011016|orbit I think this is a mailing list post explaining what they're trying to accomplish, but it's long and I can't find a decent threaded version of the conversation. http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg02398.html This works for me (for now). compile module( "org.eclipse.jetty:jetty-server:8.1.2.v20120308" ) { dependencies( "org.eclipse.jetty.orbit:javax.servlet:3.0.0.v201112011016@jar" , "org.eclipse.jetty:jetty-continuation:8.1.2.v20120308" , "org.eclipse.jetty:jetty-http:8.1.2.v20120308" ) } There's also jbi-component and jbi-shared-library suggested in IVY-899. I might be wrong, but Maven seems to default to jar if <type></type> isn't specified in the dependency declaration. Would defaulting to jar for unknown packaging types cause problems with Gradle (or Ivy for that matter)? Edit: JETTY-1493
        ldaley Luke Daley made changes -
        Issue Type Task [ 3 ] Improvement [ 4 ]
        ldaley Luke Daley made changes -
        Workflow jira with pivotal tracker [ 15232 ] jira with pivotal tracker (no resolved, only closed) [ 18755 ]
        Status Resolved [ 5 ] Closed [ 6 ]
        ldaley Luke Daley made changes -
        Workflow jira with pivotal tracker (no resolved, only closed) [ 18755 ] Copy of jira with pivotal tracker (no closed, only resolved) [ 21352 ]
        Status Closed [ 6 ] Resolved [ 5 ]

          People

          • Assignee:
            daz Daz DeBoer
            Reporter:
            forums Gradle Forums
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development