Maven-publish plugin generated pom making dependency scope runtime

Old Forum
1

It appears that the incubating maven-publish plugin makes the scope of all dependencies in the generated pom runtime. This is causing us some problems because some of these transitive dependencies that we have actually need to be on the compile classpath, but since they are marked as runtime, maven does not have them.

This stack overflow topic (http://stackoverflow.com/questions/20131915/publishing-artifact-from-gradle-project-to-bintray-maven-repository) seems to reference this as a known issue, but I could not find anything here on the gradle forum.

If there is not already a jira issue created, I would like one created.

We are using gradle 1.8 on centos and mac laptops boxes.

$ gradlew --version
  ------------------------------------------------------------
Gradle 1.8
------------------------------------------------------------
  Build time:
 2013-09-24 07:32:33 UTC
Build number: none
Revision:
   7970ec3503b4f5767ee1c1c69f8b4186c4763e3d
  Groovy:
     1.8.6
Ant:
        Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy:
        2.2.0
JVM:
        1.7.0_45 (Oracle Corporation 24.45-b08)
OS:
         Mac OS X 10.8.5 x86_64
2 Likes
2

It’s a known limitation of the incubating ‘maven-publish’ plugin. Until this gets fixed, your options are:

  • Use the ‘pom.withXml’ hook to fix the dependency scopes as needed * Use the “old” ‘maven’ plugin
3

I found a reference to this problem in GRADLE-784, but there was no explicit link to an existing issue there either.

4

Is there a jira to track this known issue? If not, can we create one?

Also, how would I use the pom.withXml hook? Would I have to explicitly re-define every dependency?

5

I have the same issue.

I have to user ‘maven-publish’ as I guess bintray gradle plugin depends on that. So using the old maven plugin doesn’t look like a great option.

Is there any update on either JIRA issue on in general if this issue is going to be fixed in near future?

6

Any updates on the issue? I’ve fixed that by preserving compile scope in generated pom.xml:

publishing {
 publications {
     pom.withXml {
         asNode().dependencies.'*'.findAll() {
             it.scope.text() == 'runtime' && project.configurations.compile.allDependencies.find { dep ->
                 dep.name == it.artifactId.text()
             }
         }.each() {
             it.scope*.value = 'compile'
         }
     }
    }
}
7

There isn’t currently an automatic way to do this (except for using the ‘maven’ plugin).

8

pom.withXml {} needs to be placed within a publication element. Great tip, though, we have just used it during the gradleware training.

9

@Szczepan, can you give an example like the one above as you described, withing a publication element? I need to override versions in the generated POM as I change the resolution strategy at runtime to use different versions than those specified in dependencies.

10

Basically the example above is missing information what publication the pom modification is applied to. Either “publications.all {}” needs be used or specific publication: “publications.myPublication(…) {}”

Complete example using ‘all’:

publishing.publications.all {
  pom.withXml {
    asNode().dependencies.'*'.findAll() {
      it.scope.text() == 'runtime' && project.configurations.compile.allDependencies.find { dep ->
        dep.name == it.artifactId.text()
      }
    }.each { it.scope*.value = 'compile'}
  }
}
2 Likes
11

I see. Do you not need to pass the MavenPublication to myPublication?

12

AFAIR, this depends whether you’re creating a new publication (you need the type) or you’re referring to an existing publication (you need not use the type).

13

Is it really an know issue? Why there’s no update for this issue, because it’s almost a year since this topic started…

14

Is there an existing JIRA issue to resolve this or can one be created?