Mysterious "maven" publication from nowhere

[rekire]

I'm working on an open source library where I have multiple modules which represent each a single artifact.

Here is my code:

publishing.publications {
    ssmlPlugin(MavenPublication) {
        groupId = 'org.rewedigital.voice.dialog'
        artifactId = 'ssml-plugin'
        //...
        pom {
            name = 'dialog'
            description = 'This is the SSML-Builder plugin for Dialog to write voice applications fast.'
            url = 'https://github.com/rewe-digital-incubator/dialog'
            licenses { // ...

^{full code}

I'm creating there a custom pom file since I was not sure how to do that with your plugin. In the end here is the partial redundant publish block:

publish {
    userOrg = 'rewe-digital'
    groupId = 'org.rewedigital.voice.dialog'
    artifactId = 'ssml-plugin'
    repoName = 'dialog'
    publishVersion = rootProject.ext.versions.core
    desc = 'This is the SSML-Builder plugin for Dialog to write voice applications fast.'
    website = 'https://github.com/rewe-digital-incubator/dialog'
    licences = ['MIT']
    bintrayUser = project.properties['bintray.user']
    bintrayKey = project.properties['bintray.apikey']
    dryRun = false
    publications = ['ssmlPlugin']
}

This works fine so far. Just when I reference the "core" module from another module (via implementation project(":core")) it keeps crashing in DefaultProjectDependencyPublicationResolver with an exception like this:

java.lang.UnsupportedOperationException: Publishing is not able to resolve a dependency on a project with multiple publications that have different coordinates.
Found the following publications in project ':core':

• Maven publication 'core' with coordinates org.rewedigital.voice:dialog:1.0 <- correct one!
• Maven publication 'maven' with coordinates org.rewedigital.voice:core:1.0 <- does not even exists!

(Please note that this error is from a different module which is not yet pushed, however it is the same error)

For some reasons there is a 'maven' publication which I did not define.

I also tried this workaround:

allprojects {
    afterEvaluate { project ->
        project.publishing.publications.forEach { publication ->
            if(publication.name == 'maven') {
                println('hit!')
                project.publishing.publications.remove(publication)
            }
        }
    }
}

When I check the publications then there is as expected just one, but that gradle task bintrayUpload still fails with the error above.

[mr-archano]

Hi @rekire, I was planning to take a look at the issue later this evening. Couple of questions:

• is the module you are experiencing the issue with a jvm (as in not Android) module?
• is there any repo I can checkout to troubleshoot the issue?

[StefMa]

He is talking about this: https://github.com/rewe-digital-incubator/dialog/blob/master/ssml-plugin/build.gradle

…

On Tue, Feb 26, 2019, 5:42 PM Antonio Bertucci ***@***.***> wrote: Hi @rekire <https://github.com/rekire>, I was planning to take a look at the issue. Couple of questions: - is the module you are experiencing the issue with a jvm (as in not Android) module? - is there any repo I can checkout to troubleshoot the issue? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#266 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwYe_VhJZDnkPTQE_WvJJSb3_DdzNv4ks5vRWPrgaJpZM4bSLyi> .

[mr-archano]

Hi @rekire I just checked and you're right, the problem is that the bintray-release plugin is creating a maven pubblication for projects applying the java gradle plugin. On top of that the customisation of the artifacts is not working as expected either, this has been raised recently too.

I hacked something together that should provide what you are looking for:
https://github.com/mr-archano/dialog/commit/4f17627496dbd5d389d294e7cb7c5f70e630e195
The idea is to intercept the maven publication created by the bintray-release plugin and reconfigure it as needed. I believe it should be feasible to allow custom configuration of publications extending the plugin DSL, I already have some idea in mind, but in the meantime the hacks in the commit above could help.

[rekire]

I tried to apply that to my core module then it seems that no artifact will be created:

> Task :core:bintrayUpload
Uploading to https://api.bintray.com/content/rewe-digital/dialog/core/1.0/org/rewedigital/voice/core/1.0/core-1.0-sources.jar...
Uploading to https://api.bintray.com/content/rewe-digital/dialog/core/1.0/org/rewedigital/voice/core/1.0/core-1.0-javadoc.jar...
Uploading to https://api.bintray.com/content/rewe-digital/dialog/core/1.0/org/rewedigital/voice/core/1.0/core-1.0.pom...

Do you have an idea why?

[rekire]

I just executed your branch, the main artifact is now missing :/

[mr-archano]

@rekire just to be clear: when working on that branch I was running this command

 gw -p ssml-plugin clean build bintrayUpload

Basically the "fix" is applied only to the ssml-plugin module, I haven't touched the others.

[rekire]

$ ./gradlew -p ssml-plugin clean build bintrayUpload
> Task :ssml-plugin:dokkaJavadoc
No documentation for org.rewedigital.dialog.utils$withGoogleSimpleResponse(org.rewedigital.dialog.handler.DialogflowResponseBuilder, org.rewedigital.dialog.ssml.SsmlBuilder) (SsmlExtensions.kt:8)
No documentation for org.rewedigital.dialog.utils$withSimpleResponse(org.rewedigital.dialog.model.google.RichResponse, org.rewedigital.dialog.ssml.SsmlBuilder) (SsmlExtensions.kt:12)

Task :ssml-plugin:bintrayUpload
Uploading to https://api.bintray.com/content/rewe-digital/dialog/ssml-plugin/1.0/org/rewedigital/voice/dialog/ssml-plugin/1.0/ssml-plugin-1.0-sources.jar...
Uploading to https://api.bintray.com/content/rewe-digital/dialog/ssml-plugin/1.0/org/rewedigital/voice/dialog/ssml-plugin/1.0/ssml-plugin-1.0-javadoc.jar...
Uploading to https://api.bintray.com/content/rewe-digital/dialog/ssml-plugin/1.0/org/rewedigital/voice/dialog/ssml-plugin/1.0/ssml-plugin-1.0.pom...

BUILD SUCCESSFUL in 11s
13 actionable tasks: 13 executed

There are just two jars that should be three.

[rekire]

I'm still checking it, but I guess I found a solution for the missing jar. I just need to add artifact(jar) to line 55 of your modified file

[rekire]

Yet another update: While it seems to work fine. I found out that now the dependencies are missing in the pom file.

You can see my current adaptation here: https://github.com/rewe-digital-incubator/dialog/blob/alexa_plugin/publish.gradle

[rekire]

I found some open ends to wire all the things together. However that falls in my top 5 of my hackiest solutions to resolve a problem which I really prefer not to use on an open source project.

With configurations.getByName("compile").getDependencies() I can get the compile dependencies which can be AFIK one of those two classes DefaultExternalModuleDependency or DefaultProjectDependency. Both classes have the "groovy" properties group, name and version, so it is easy to get them.

My solution to inject them into the pom would use reflection something like that:

def mavenPublicationField = publication.pom.getClass().getSuperclass().getDeclaredFields().findResult { it.name == "mavenPublication" ? it : null }
mavenPublicationField.setAccessible(true)
def mavenPublication = mavenPublicationField.get(publication.pom)
def mavenDependencyConstructor = Class.forName("org.gradle.api.publish.maven.internal.dependencies.DefaultMavenDependency").getConstructor(String.class, String.class, String.class)
mavenPublication.getApiDependencies().add(mavenDependencyConstructor.newInstance("group", "art", "ver"))

Pleaaaaase offer me a better solution 😃

[mr-archano]

@rekire I hear you, and I believe that it would be possible to provide that functionality you need assuming that the plugin we use underneath (gradle-bintray-plugin) offer that functionality.

I agree that using the dependencies as you mentioned is a bit hacky, and the generation of the pom file is something that gave us so much trouble in the past I had to basically rewrite the way the Android artifacts are collected (if you are curious see the long conversation in #177 and #249 as crazy solution for that).

Solving your issue while not breaking any of the work introduced in #249 sounds like an amount of effort I can't commit to at the moment because of a very busy schedule at work, but I promise that this is on my todo list and will keep you posted if any update :)

[rekire]

I guess I found now a clean solution.

I will validate the results later and will create a pull request if it really works fine.

My current idea is to define myself the "maven" publication before you do that. The patch now is to check in your plugin if there is already a maven publication and avoid to create a default publication which makes trouble in my case.

Here just to get the point (ReleasePlugin):

project.plugins.withId('java') {
    def mavenConfig = project.publishing.publications.find {it.name == 'maven'}
    if(mavenConfig == null) {
        String publicationName = 'maven'
        MavenPublication publication = createPublication(publicationName, project, extension)
        new JavaAttachments(publicationName, project).attachTo(publication)
    }
}

[mr-archano]

#267 is now merged to develop, so a new snapshot with those changes is available: https://github.com/novoda/bintray-release#snapshots

As mentioned in the PR before we roll out a full release we should keep the Android support in feature parity and document how to customise the MavenPublication.