Using the maven-publish plugin = no dependencies in pom.xml

Old Forum Archive
1

I have just upgraded my projects to use the maven-publish plugin instead of the maven plugin. Previously (with the maven plugin) I build my projects with:

gradle clean --refresh-dependencies install uploadArchives

As a result an artifact and a pom.xml where uploaded to our internal repository. The generated pom.xml file would contain all the dependencies, making it possible for “clients” to get all transitive dependencies when downloading the published artifact.

Now I build with:

gradle clean --refresh-dependencies publish

but the generated pom.xml file does not contain any dependencies only the coordinates for the artifact it self. What has changed in how the generated pom.xml file is published?

2

How are you configuring your maven publication? You’ll need to follow the instructions laid out in http://www.gradle.org/docs/nightly/userguide/publishing_maven.html.

3

Like this:

project.publishing {
      publications {
        mavenJava(MavenPublication) { from project.components.java }
      }
      repositories {
        maven {
          credentials {
            username "admin"
            password "password"
          }
          if(project.version.endsWith('-SNAPSHOT')) {
            url "http://xxx"
          } else {
            url "http://xxx"
          }
        }
      }
    }
4

Your project POM should get all of the dependencies added to the ‘runtime’ configuration (and by extension the ‘compile’ configuration as well). It’s worth printing out the contents (from inside the publishing block).

project.publishing {
    publications {
        mavenJava(MavenPublication) { from project.components.java }
    }
    println configurations.runtime.allDependencies
}

The reason for doing this inside the publishing block is that the dependencies must have been added to configuration at the time that the publishing block is evaluated. The ‘publishing’ block is configured late, but any direct access to ‘project.publishing’ can force it’s evaluation.

5

I am running into the same problem with 1.7-rc-1. My maven publication configuration is identical to the one posted above. My build.gradle (which is for a subproject) looks like this:

dependencies {
    compile group: 'commons-jxpath', name: 'commons-jxpath', version: '1.3'
    testCompile(
            [group: 'com.google.code.gson', name: 'gson', version: '2.2.2']
    )
}

Is there something more I need to configure?

6

I believe I have come up with a minimal reproduction recipe for this. The problem seems to be triggered by using a compile project dependency.

Create a multi-project build structured so:

exp/
  nom/
  util/

exp/build.gradle:

subprojects {
    apply plugin: 'java'
    apply plugin: 'maven-publish'
      group = 'my.org'
    version = '1.0.0-SNAPSHOT'
      publishing {
        publications {
            mavenJava(MavenPublication) {
                from components.java
            }
        }
    }
}

exp/nom/build.gradle:

dependencies {
    compile project(':util') // POMs are generated correctly if I comment out this line
}

exp/util/build.gradle:

dependencies {
    compile group: 'commons-jxpath', name: 'commons-jxpath', version: '1.3'
}

Generate POMs:

exp$ gradle generatePomFileForMavenJavaPublication

The pom.xml generated for util does not contain any transitive dependencies. The pom.xml generated for nom does.

If I remove the compile project dependency from nom/build.gradle, then the pom.xml for util is generated with the correct transitive dependencies.

7

I’m not sure what behaviour you’re seeing, or what you’re expecting to see, but here’s what I get (which is what I expect):

subprojects {
    apply plugin: 'java'
    apply plugin: 'maven-publish'
    group = 'my.org'
    version = '1.0.0-SNAPSHOT'
    repositories {
        mavenCentral()
     }
    publishing {
        publications {
            mavenJava(MavenPublication) {
                from components.java
            }
        }
    }
}
project(':util') {
    dependencies {
        compile group: 'commons-jxpath', name: 'commons-jxpath', version: '1.3'
    }
}
project(':nom') {
    dependencies {
        compile project(':util')
    }
}

The pom file generated for the ‘util’ project has the commons-jxpath dependency:

<dependencies>
    <dependency>
      <groupId>commons-jxpath</groupId>
      <artifactId>commons-jxpath</artifactId>
      <version>1.3</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>

and the pom file for the ‘nom’ project includes the dependency on ‘util’:

<dependencies>
    <dependency>
      <groupId>my.org</groupId>
      <artifactId>util</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>

Is that what you’re seeing?

1 Like
8

I expect to see what you are seeing. However, here is what gets generated for my util project:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>my.org</groupId>
  <artifactId>util</artifactId>
  <version>1.0.0-SNAPSHOT</version>
</project>
9

The generated POM for my nom project appears to be correct:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>my.org</groupId>
  <artifactId>nom</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <dependencies>
    <dependency>
      <groupId>my.org</groupId>
      <artifactId>util</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>
1 Like
10

One more data point: if I use gradle 1.6, then the dependencies are generated correctly for the util project.

11

I’ve just tested my build script above with both ‘gradle-1.6’ and ‘gradle-1.7-rc-1’. It’s behaving correctly for me in both instances.

Can you confirm that this is indeed a problem, and provide a complete, self-contained example (like the one I presented)? It might also be worth running with --info to see if that gives any hints.

12

This is indeed a problem.

The minimal reproduction recipe I provided above is as self-contained as I can get it. Crucially, if I flatten everything into a single build script (as you did above), the problem disappears. Can you try structuring the build.gradle scripts as I did above?

13

I’ve split the build scripts out, and now I can replicate the behaviour you’re seeing. I’ll have to investigate further, but this does seem to be a regression in 1.7-rc-1.

I’ll get back once I’ve worked out what’s going on.

14

This is indeed a regression in ‘gradle-1.7-rc-1’. I’ve raised GRADLE-2837 to track the fix.

15

Thank you, Daz.

16

Any update on this?

I’m using gradle 1.10 and experiencing this same regression from 1.7-rc-1. If we use the ‘maven’ plugin then it generates our poms correctly. However, if we use the ‘maven-publish’ plugin, then it exhibits the bug described in GRADLE-2837.

The problem we’re having is that we’re using the ‘publishToMavenLocal’ functionality of the ‘maven-publish’ plugin so that developers can work on feature branches without pushing those versions to the shared maven repo.

However, when that feature work is complete and we run “gradle clean build publish” it doesn’t include the dependencies properly, in the same way described in this thread.

17

GRADLE-2837 was fixed in Gradle-1.7-rc-2 (and final). It’s likely you’re seeing a different problem.

Please create a new forum entry describing your problem in detail, including the way your dependencies are being declared and the actual pom file output you’re getting.

18

Sure thing. As soon as I get a moment, I’ll create a bare-bones example that reproduces this problem and post a new forum entry.

19

Did this ever get resolved? I have the same problem in Gradle 1.10?

20

No. Overworked at my last job, I never had the free time to provide a good example of this. I’m finding a new position, now, with a much shorter commute. So, hopefully, I’ll be able to circle back and prove that Android AAR dependencies are not being included in the POM that gets produced by the ‘maven-publish’ plugin. As a work-around, we ended using “uploadArchives,” from the ‘maven’ plugin, instead.