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

Old Forum Archive
1

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)?

2

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: http://gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies. 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.

3

This is now GRADLE-2076

4

From the maven docs, I don’t think there is a finite set of valid packaging values. The docs seem to indicate that new packaging types can be created along with plugins to handle those packaging types.

My idea was that in lieu of a plugin for a packaging type, I’d simply like to override the name mapping; in this case eclipse-plugin --> jar by setting classifier, type and extension.

From the link you provided, it seems like I can accomplish this by putting the following in my dependencies stanza:

jacocoAgent "org.jacoco:org.jacoco.agent:0.5.6+@jar"

which seems to solve the problem of resolving the jacoco agent dependency and getting the jars onto my classpath.

Thanks for your help.

5

The docs seem to indicate that new packaging types can be created along with plugins to handle those packaging types.

That’s correct. A plugin can define its own packaging type. This Stack Overflow thread covers the details.

6

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).

{code} 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”

) } {code}

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 {{}} isn’t specified in the dependency declaration. Would defaulting to {{jar}} for unknown packaging types cause problems with Gradle (or Ivy for that matter)?

7

Since GRADLE-2076 was resolved prior to the discovery / report of “orbit” packaging, I created a new issue GRADLE-2188 to cater for that particular case.