Hello!
maven-publish plugin does not create pom with all specified information like licensies, developers, etc…
Source code:
resulting plugin:
https://plugins.gradle.org/m2/com/github/axet/gradle-android-dx/0.0.6/
Am I missing some props or this is a bug to report?
This is working as expected. You are creating a different publication called mavenJava with these extra properties that would be published to Maven Central. You are not configuring these properties on the pluginMaven publication created by the com.gradle.plugin-publish plugin, which is the publication published to the plugin portal.
Problem is when I publish this project to maven central those properties (licence and developers) are not published! It is not just about gradle plugins portal. I unable to republish plugin to maven central with this configuration because uploaded pom.xml is filtered. The command I’m using to publish to gradle repository:
./gradlew publishGradle
command for maven central:
./gradlew publish
same pom.xml! which looks like a bug!
I’ve been able to publish this plugin to maven central only by using ‘com.vanniktech:gradle-maven-publish-plugin:0.19.0’
Your original post stated that the maven-publish plugin was not creating a POM with all of the specified information and you provided a link to the plugin published on the portal as the evidence. With the information provided, it is the case that:
maven-publish plugin for the mavenJava publication that you’ve configured does contain these values (an excerpt of the file generated from your build is below).It is not easy for us in the forums to be able to reproduce the entire publishing process to troubleshoot what is specifically going wrong in your particular build. However, it is pretty easy to see that Gradle is generating the right POMs for what you’ve configured initially. I would recommend that you use this information to further investigate what is happening later in the process and come back with more specific questions, if you have them. I agree that you’re not getting what you want, but the problem is not where you’re saying it looks like a bug.
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://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">
<!-- This module was also published with a richer model, Gradle metadata, -->
<!-- which should be used instead. Do not delete the following line which -->
<!-- is to indicate to Gradle or any Gradle module metadata file consumer -->
<!-- that they should prefer consuming it instead. -->
<!-- do_not_remove: published-with-gradle-metadata -->
<modelVersion>4.0.0</modelVersion>
<groupId>com.github.axet</groupId>
<artifactId>gradle-android-dx</artifactId>
<version>0.1.1</version>
<name>Gradle Android dx plugin</name>
<description>Compile dependencies (.jar files) into android 'assets' folder (.dex files)</description>
<url>https://gitlab.com/axet/gradle-android-dx</url>
<licenses>
<license>
<name>GNU LESSER GENERAL PUBLIC LICENSE 3.0</name>
<url>http://www.gnu.org/copyleft/lesser.html</url>
</license>
</licenses>
<developers>
<developer>
<id>axet</id>
<name>Alexey Kuznetsov</name>
<email>axet@me.com</email>
</developer>
</developers>
<scm>
<connection>scm:git:https://gitlab.com/axet/gradle-android-dx</connection>
<developerConnection>scm:git:https://gitlab.com/axet/gradle-android-dx</developerConnection>
<url>https://gitlab.com/axet/gradle-android-dx</url>
</scm>
...
My bad. I should point out ‘./gradle GenerateMavenPom’ is generating correct pom file. The problem with maven-publish which strip the pom file before publish to maven central. Which exactly what you are saying. Except you ask my help to investigate why is it happening… No problem I can do it.
But t is clear now ‘maven-publish’ does something wrong, ‘gradle publish’ should work from the box.
So? Can I report a bug against maven-publish which strips pom files? And simultaneously investigate why is it happening?
You can report any bug you want at GitHub issues, but it will most likely be closed, because the maven-publish plugin does not strip any information from any POM file. It just uploads the POM that is generated for the publication that is published.
Your problem is, that you have three publications. The dxPluginPluginMarkerMaven publication and the pluginMaven publication created by the java-gradle-plugin for you and the mavenJava publication you create yourself. And you define as publishing repository Maven Central.
Publishing repositories and Publications are side-by-side and result in a task for each combination.
So for the maven publishing repository you defined, you get the tasks.
publishDxPluginPluginMarkerMavenPublicationToMavenRepository - Publishes Maven publication 'dxPluginPluginMarkerMaven' to Maven repository 'maven'.
publishMavenJavaPublicationToMavenRepository - Publishes Maven publication 'mavenJava' to Maven repository 'maven'.
publishPluginMavenPublicationToMavenRepository - Publishes Maven publication 'pluginMaven' to Maven repository 'maven'.
Now when you call publish, you probably first get publishMavenJavaPublicationToMavenRepository executed which uploads the correct POM and then publishPluginMavenPublicationToMavenRepository wich overwrites it with the incorrect POM, resulting in the error you see.
So as James already said, you should not create a new publication but just configure the existing publication named pluginMaven to add your POM attributes.
Btw. when publishing to Maven Central I greatly recommend using the GitHub - gradle-nexus/publish-plugin: Gradle plugin for publishing to Nexus repositories plugin to avoid certain problems and make it smoother.
Btw. actually your project has another (imho) major bug, it is missing half of the Gradle wrapper files.
Thank you very much! Now I understand! The problem is documentation for maven plugin, it states nothing about long-term-task-names and correct pom generation!
With your explanation I now able to publish correct pom.xml to booth local and maven repositories!
./gradlew publishMavenJavaPublicationToMavenLocal publishMavenJavaPublicationToMavenRepository
The only thing I did not agree with - puting shell and binary scripts into source repository - this is barbaric!
I guess we need to update documentation related to maven-publish!
EDIT: ‘./gradlew publish’ not just override correct pom.xml, it also forget to update .asc signature. Bad design!
Thank you very much! Now I understand! The problem is documentation for maven plugin, it states nothing about long-term-task-names and correct pom generation!
I don’t know what you mean by that.
The documentation is fine imho.
It states exactly which tasks are created for a publication.
What do you expect if you create two publications that publish under the same coordinates?
That even sounds totally wrong, which it also is.
./gradlew publishMavenJavaPublicationToMavenLocal publishMavenJavaPublicationToMavenRepository
Well, I still think you should not create a third publication that publishes under the same coordinates as one of the other two, but simply configure the pluginMaven publication instead, then you also don’t have to be careful to just run the correct tasks but can simply use publish again. But well, whatever works for you.
The only thing I did not agree with - puting shell and binary scripts into source repository - this is barbaric!
It is not barbaric, it is how the Gradle wrapper is designed to work.
If you leave out any of the four files, the wrapper is not properly usable, except for 3rd party tools that only read the version from the properties file like the IDE.
But anyone just wanting to run your build cannot properly do it.
I’m also strictly against putting build artifacts to VCS, even generated code, these things should always be generated by the build.
But these files are not generated by your build but are what you run the build with.
Well, do whatever you think is right for you, but as I said, iMo every project that misses one of the four wrapper files has a serious bug, you just make it harder for anyone wanting to run your build.
I guess we need to update documentation related to maven-publish!
I wouldn’t know where, the docs are pretty clear and correct in my opinion.
But if you think so, open a feature request or pull request.
I’m just a user like you.
EDIT: ‘./gradlew publish’ not just override correct pom.xml, it also forget to update .asc signature. Bad design!
Not at all, just bad configuration on your side.
You have publication pluginMaven and you have publication mavenJava which both publish under the same coordinates.
You only enable signing for the mavenJava publication.
Then you first do the mavenJava publishing and after that the pluginMaven publishing.
So of course the pluginMaven artifacts override the mavenJava artifacts.
But as you didn’t configure signing for the pluginMaven publication, the signatures of course stay untouched.
I do not understand you. Let me answer your questions by asking another question: why are you keep saying I have two publications, when it is clear, I declared only one publication in ‘build.gradle’ called mavenJava?
If you check docs, it is clear, here is no mention for ‘pluginMaven’ publication and how to ‘undeclare’ it. Also it is clear, here is no mention for ‘publishMavenJavaPublicationToMavenLocal’ task. That is why I miss it completely and having other issues publishing the gradle plugin. Also I should mention, I’m writing and publishing gradle plugin, having ‘pluginMaven’ publication confusing me since it is opposite to what I’m doing. The name suggest it is maven plugin, but is not! Docs should be changed to correspond those problems and it will be (I already have an issue and it is accepted).
You can check docs, no mentions for points I made:
https://docs.gradle.org/current/userguide/publishing_gradle_plugins.html
https://docs.gradle.org/current/userguide/publishing_maven.html
Few words about gradle it self. Gradle brakes java ideology by creating runtime types and then operate with those types - basically replacing the java compiler with a programmer. We used to code, now we compile types to create classes and run them in the same script file. Some may call it flexibility, I’m calling it - bad design. Same as putting binaries into source repository - source repository used to be repository of text files, now - it hold compiler to compile types which compile classes and run those classes! If you are developer you have developer tools installed, including gradle on your machine. Do not need to put all your tools into source repository (same crazy idea as dynamic gradle types). To summary - gradle is bad design, and I touch it only because of Google and Android.
I do not understand you. Let me answer your questions by asking another question: why are you keep saying I have two publications, when it is clear, I declared only one publication in ‘build.gradle’ called mavenJava?
I never said you ahve two publications.
I said you have three publications.
Which is the simple truth as you can also see from the output of the tasks task.
I also explained to you which publications those are and that “you” create the other two by applying the java-gradle-plugin plugin.
Maybe you should simply read my answers again more closely. 
If you check docs, it is clear, here is no mention for ‘pluginMaven’ publication and how to ‘undeclare’ it.
Indeed it is missing in the docs, and that you should report.
But it has nothing to do with the maven-publish plugin.
As already stated, the java-gradle-plugin adds those publications, the pluginMaven publication and one publication for each plugins marker artifact. Btw. if you do the publishing to Maven Central like you did now, then you will miss the plugin marker artifacts, so you cannot resolve the plugin from ID, except if you publish to Plugin Central too and use that as plugin repository.
The docs for the java-gradle-plugin at Gradle Plugin Development Plugin are indeed a bit too concise and just mention that it configures the publishing for the marker artifacts. But it indeed does mention how to prevent it being done, which is the isAutomatedPublishing property. But again for the third time or so, why should you bother to do that? Just don’t create an additional publication but simply configure the publication the plugin already properly configured for you and you have no problems and maximum convenience.
Also it is clear, here is no mention for ‘publishMavenJavaPublicationToMavenLocal’ task.
That’s totally untrue.
Just look properly at Maven Publish Plugin.
Of course the concrete task name is not mentioned, but the pattern how the task names are built, from publication name and repository name.
The concrete names simply cannot be listed in the documentation as they fully depend on how you configure your build.
having ‘pluginMaven’ publication confusing me since it is opposite to what I’m doing. The name suggest it is maven plugin, but is not!
It does not. It suggests that the publication publishes the plugin to a maven repository which is exactly what you are doing.
Docs should be changed to correspond those problems and it will be (I already have an issue and it is accepted).
Well, we simply don’t agree there are problems except for the missing information on the java-gradle-plugin documentation chapter. But as I said, I’m just a user like you. That you have to negotiate with the Gradle guys. 
To summary - gradle is bad design, and I touch it only because of Google and Android.
Well, I’m not going to start discussing this, I’m just telling you once my opinion. Gradle is simply the best build tool that exists and the overall design is great. The wrapper is an amazing thing that even Maven copied to their project too because it is simply a great idea to eradicate the the problem of failing builds or builds silently doing wrong things just because of an incompatible build tool version used to build it. If you don’t agree and don’t like Gradle, simply don’t use it.
Thank you for clear things out. I understand gradle much better right now.