18

I'm trying to create a gradle based multi-module project. There is also an project that contains different gradle scripts that enables pluggable build configurations. One of those scripts is for publishing artifacts to maven repository. This is the content of that script:

apply plugin: 'maven-publish'

configure(subprojects.findAll()) {
    if (it.name.endsWith('web')) {
        publishing {
            publications {
                mavenWeb(MavenPublication) {
                    from components.web
                }
            }
        }
    } else {
        publishing {
            publications {
                mavenJava(MavenPublication) {
                    from components.java
                }
            }
        }
    }
}

build.dependsOn publishToMavenLocal

This script is included in the build gradle file of other project.

apply from: '../../food-orders-online-main/artifact-publish.gradle'

When I run build task it always shows that publishToMavenLocal task is up to date and I cannot find the artifacts in the local repository. Am I doing something wrong?

Rade Milovic
  • 965
  • 4
  • 13
  • 29
  • Perhaps check the --info and --debug logs. – Peter Niederwieser Oct 26 '14 at 21:25
  • :food-orders-online-admin-business:publishToMavenLocal (Thread[main,5,main]) sta rted. :food-orders-online-admin-business:publishToMavenLocal Skipping task ':food-orders-online-admin-business:publishToMavenLocal' as it has no actions. :food-orders-online-admin-business:publishToMavenLocal UP-TO-DATE :food-orders-online-admin-business:publishToMavenLocal (Thread[main,5,main]) com pleted. Took 0.007 secs. – Rade Milovic Oct 26 '14 at 21:51
  • I already know that task is skipped. My question is why. I think that subprojects.findAll() doesn't return anything. Then how can I access all sub-projects? I can do it in every project separately, but it's repetitive and stupid if I can do this. – Rade Milovic Oct 26 '14 at 21:52

2 Answers2

58

By adapting answer from here, it works for me.

publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
    repositories {
        mavenLocal()
    }
}
Community
  • 1
  • 1
heading
  • 691
  • 5
  • 3
  • 1
    Ref: https://docs.gradle.org/current/userguide/publishing_maven.html – dkb Nov 08 '19 at 10:46
  • 2
    Is the `mavenLocal()` bit required? The link provided by @dkb states: "You do not need to have `mavenLocal()` in your `publishing.repositories` section." – M. Justin Oct 14 '20 at 22:18
  • 3
    @M.Justin the `repositories.mavenLocal` part is not required. My setup doesn't have it and my artefacts still get published to my local `.m2`. – Bruno Gasparotto Dec 16 '20 at 14:30
  • this made my day. It worked for me. There where many other ways suggested over various posts but only this worked for me. Thanks :) – Arpit Tripathi May 29 '21 at 12:58
6

I think this could be a manifestation of a bug with gradle, that modules can lose the publishMavenJavaPublicationToMavenLocal task when they are depended upon in a certain way.

If gradle determines that there is no publishMavenJavaPublicationToMavenLocal task for a module then the publishToMavenLocal task will always report that it is up to date.

The specific case I have found occurs in a multimodule setup, with multiple levels of nested modules. It can be summarised as follows, where shared:domain loses its publishMavenJavaPublicationToMavenLocal when depended upon by A

root
root gradle build file
->A
  own gradle build file with dependency on shared:domain
-> shared
    gradle build file for shared modules
     -> shared:domain
     -> shared:B

I have created a small example project demonstrating this behaviour available here - https://github.com/piersy/Gradle2MavenPublishBug

I have also logged a bug with gradle here - http://forums.gradle.org/gradle/topics/the-publishmavenjavapublicationtomavenlocal-task-disappears-from-a-project-when-that-project-is-depended-upon-in-a-specific-way

For now the workarounds I have found are to

  1. Remove A's dependency on shared:domain
  2. Make A a submodule with its configuration specified in its parent module build file
  3. Give shared:domain its own gradle build file
PiersyP
  • 5,003
  • 2
  • 33
  • 35
  • Thank you for such detailed and well explained answer. I think I will go with a third workaround in my case. I also hope that Gradle team will solve this issue soon. – Rade Milovic Jan 08 '15 at 16:37
  • Given how long it took me to track this bug down, I was very happy to be able to share the workarounds with someone. – PiersyP Jan 08 '15 at 17:45
  • 2
    Maybe you should raise it in the [issue tracker](https://issues.gradle.org/browse/GRADLE) rather than on the forum. – Mirko N. Jan 18 '15 at 23:08
  • Hi Mirko, I would love to, but as far as I can see the only way to raise an issue is through the forum, if you know otherwise please provide me the link where I can sign up to add bugs to the issue tracker. Thanks – PiersyP Jan 19 '15 at 09:36
  • 1
    @Karl The text on the page you linked linked says "If you are looking to report a problem with Gradle, please use discuss.gradle.org to create a "bug" post" and the link in my post above is to such a bug report, that I filed almost 2 years ago. – PiersyP Aug 05 '16 at 11:43
  • @PiersyP I oversaw that. I'm right, though, no one will look into a forum for old issues. Why make things smart/let contributors use your issue tracker if you can do it this way?!? – Kalle Richter Aug 05 '16 at 13:05
  • @Karl I don't know! I have never tried to sign up for the tracker since the advice given by gradle is explicitly not to use it. We actually stopped using gradle about a year ago because of this and other issues. Please feel free to copy this my post into the tracker. – PiersyP Aug 05 '16 at 13:54
  • I can't do that neither. They seriously don't allow write access for registered users. The fact that they advise it doesn't make it a smart idea. – Kalle Richter Aug 05 '16 at 17:28