Gradle: Stable Publishing Plugins

[bmuschko]

Users can decide between the old Maven plugin and the "new" Maven publishing plugin. The same goes for ivy vs. ivy-publish. Most of the time this choice is confusing because feature sets and runtime behaviors are different. Remove the "old" Maven plugin. Implement missing features (e.g. signing) in the "new" Maven publishing plugin.

Expected Behavior

There's one definitive plugin for publishing. Existing bugs are fixed for the plugin. The old plugin is removed from the Gradle code base.

Current Behavior

Users have to make a choice between two publishing plugin.

[sebersole]

As noted multiple places, it is ridiculous that the (perpetually incubating) maven-publish plugin still does not support signing. I'm going to take a stab at plugin-ifying support for this - the Gradle team can do what they want with this (or nothing)... I will have support for it

[eriwen]

@sebersole we certainly cannot fault you for being frustrated here. I think the very least we could do is provide some guidance for your plugin and hope it gets us closer to a long-term solution— is that something you or someone from the team can provide @oehme?

[sebersole]

I'm actually pretty far along already. One problem I am hitting is described here : https://discuss.gradle.org/t/access-generatepomfilefor-publication-from-plugin-code/25426

Hopefully I get that figured out, I can push an example of what this is looking like.

[sebersole]

To clarify... I am pretty far along doing this as a completely external plugin, using nothing but gradleApi(). This could be made much more concise when/if properly integrated into MavenPublishingPlugin

[jjohannes]

@sebersole for your information: We will (finally) continue working on this in the next weeks. Targeting Gradle 5.0 at the latest. I can't promise any more concrete delivery date yet, but since this work is also part of a partnership contract we have to fulfil, this will be done this year.

[sebersole]

I hope you'll forgive me if I don't hold my breath ;)

Anyway, December 2018 is a loooong time away and yet still "this year" - I need this functionality much sooner.

[jjohannes]

@sebersole that's fine of course. I just wanted to let you know. As soon as there is progress from our side, we'll update this issue.

[sebersole]

Understood. Of course if I can't get these details discussed in https://discuss.gradle.org/t/access-generatepomfilefor-publication-from-plugin-code/25426 worked out, I won't be able to go much further with this anyway.

[sebersole]

I may end up using Bintray after all, in which case all of this work was not necessary for me :smile:

But in the meantime, here is the working code: https://github.com/sebersole/gradle-clean-room2/tree/master/buildSrc

[nniesen]

Thanks @oehme for linking this. I think my use case in 1061 is similar to the Hibernate projects issue with their 'testing' artifact.

[nniesen]

Commenting on this just so the new plugin is verified for correctness.

With the maven-publish plugin in 4.7, I've noticed that running 'publishToMavenLocal' is publishing duplicate artifacts in separate folder structures. The cause might be our version of composite builds but I don't think so since it really just tweaks the multi-project resolution.

Running pTML for projectA with no includes is as expected:

.m2/com/foo/projectA

Running pTML for projectB with includes projectA creates an additional projectB folder:

.m2/com/foo/projectB 
.m2/projectB/com/foo/projectA // additional projectA artifact instead of going to .m2/com/foo/projectA

Running pTML for projectC with includes projectA and projectB creates an additional projectC folder:

.m2/com/foo/projectC 
.m2/projectC/com/foo/projectA // additional projectA artifact
.m2/projectC/com/foo/projectB // additional projectB artifact

[marcphilipp]

@nniesen Can you please create a new issue and include a complete example to reproduce the above problem?

[marcphilipp]

In Gradle 4.8, the Ivy and Maven Publish Plugins will be stable and the preferred option for publishing artifacts. 🎉

If you're reading this and currently using the old Upload-based infrastructure please migrate to the "new" plugins and let us know if there's anything that needs improvement.

[sebersole]

Does 4.8 fix any of the short-comings we've been dealing with wrt
publishing? Things like multiple artifacts for a project...

Or does it simply remove the "incubating" tag and not address these now
well-known/documented short-comings?

On Tue, May 8, 2018 at 8:30 AM Marc Philipp [e-mail]
wrote:

Closed #1165 https://github.com/gradle/gradle/issues/1165.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gradle/gradle/issues/1165#event-1615287097, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAOUE0VkmMn3gVQCv5P_4v_SVv-QoBxhks5twZ37gaJpZM4LiXly
.

[hameno]

Does signing work with the new plugins?

[oehme]

@sebersole As mentioned on the other issue, we will tackle publishing multiple libraries in 4.9, but for most users the Upload infrastructure is no longer necessary.

@hameno Yes, absolutely.

[hameno]

@oehme Are you sure?

Note: Signing the generated POM file generated by this plugin is currently not supported. Future versions of Gradle might add this functionality. Please use the Maven plugin for the purpose of publishing your artifacts to Maven Central.

from: https://docs.gradle.org/current/userguide/publishing_maven.html

[hameno]

Okay, I think I'm confused, which plugin exactly should one use for publishing artifacts to a maven repository? maven, maven-publish or the old upload?

[marcphilipp]

@hameno Did you notice the version number in the top left corner of the documentation page you've linked (it says 4.7 😉)? 4.8 RC1 will be released this Friday. If you really cannot wait, feel free to download a nightly build.

[hameno]

@marcphilipp Sorry, did not notice that 😀 Looking forward to 4.8 then 👍

[sebersole]

@oehme Ok. We'll just skip 4.8 then and wait on 4.9 to see if that bug is fixed there.

[nniesen]

Can you put deprecated on the other publishing doc pages and link to the stable one?

[marcphilipp]

We will do that eventually (see #4940). For 4.8 we've clearly marked maven-publish and ivy-publish as the preferred options but we want to fix at least the multiple publications bug mentioned above (#1061) before deprecating the old publishing infrastructure.

[Vampire]

@hameno maven is the "old upload".
If possible I'd always use the new maven-publish instead.
Signing the generated publication and especially the generated POM file needed some hacky build script.
You can see how to do it properly up to 4.7 in my next to last comment on https://discuss.gradle.org/t/how-to-publish-artifacts-signatures-asc-files-using-maven-publish-plugin/7422/23?u=vampire and how it is easily done now with a one-liner in my last comment at https://discuss.gradle.org/t/how-to-publish-artifacts-signatures-asc-files-using-maven-publish-plugin/7422/24?u=vampire now that https://github.com/gradle/gradle/issues/4943 got implemented.

[hameno]

@marcphilipp Just tried the nightly. When configuring the pom with the new syntax I cannot find a way to set the parent pom. Am I missing something?

[hameno]

I'd also like support for mavens settings.xml, especially credentials: https://github.com/gradle/gradle/issues/1236

[Vampire]

Use the withXml method or some plugin like me.tatarka.gradle.pom, which I use because it provides nicer syntax

[sebersole]

@hameno As I pointed out on that issue you linked to... I already have a plugin that does this : https://github.com/sebersole/gradle-maven-publish-auth

I completely agree with you that this should be part of Gradle proper

[marcphilipp]

Just tried the nightly. When configuring the pom with the new syntax I cannot find a way to set the parent pom. Am I missing something?

@hameno What's your use case for setting a parent POM? Usually the parent POM is used to ease development when using Maven, e.g. to inherit dependencies and plugin configuration. That doesn't apply when you use Gradle for your build.

[oehme]

Agreed, the POM DSL only supports fields that actually make sense when working with Gradle. Parent POMs don't fit that bill.

[oehme]

Let's take any further discussion to the individual issues (or create one if some request doesn't exist yet) instead of using this as a bucket list.

[Vampire]

@oehme

Agreed, the POM DSL only supports fields that actually make sense when working with Gradle. Parent POMs don't fit that bill.

But most others do, don't they, especially as couple of them are required for publishing to Sonatype / Maven Central.
I'm talking about things like url, issueManagement, developers, licenses and so on.

[oehme]

@Vampire Yes, you'll find those on the new DSL.

[Vampire]

Which new DSL?
Something that is yet to come? - When?
Or org.gradle.api.publish.maven.MavenPom, there I still only see packaging and withXml.

[oehme]

@Vampire I assume you're not looking at the nightly docs.

[marcphilipp]

@Vampire Here's an example that sets the most common things: https://docs.gradle.org/nightly/dsl/org.gradle.api.publish.maven.MavenPublication.html#N1AA73

[Vampire]

Ah nice, sorry, was looking in my checkout of April 20th.
Didn't expect it to having been changed *that * recently. :-)
Though I miss distributionManagement.downloadUrl @marcphilipp

[marcphilipp]

@Vampire We can certainly add properties if there's a use case for them. I deliberately left those properties out that I deemed unnecessary. Please create a new issue for distributionManagement.downloadUrl and explain why it might be useful. While discouraged, you can still use withXml to add it manually.

[sebersole]

Easier support for defining relocations would be nice. We've had to hack
that together a few times now

On Wed, May 9, 2018 at 12:25 PM Marc Philipp [e-mail]
wrote:

@Vampire https://github.com/Vampire We can certainly add properties if
there's a use case for them. I deliberately left those properties out that
I deemed unnecessary. Please create a new issue for
distributionManagement.downloadUrl and explain why it might be useful.
While discouraged, you can still use withXml to add it manually.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gradle/gradle/issues/1165#issuecomment-387813336, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAOUE9n7LOzrRxSQS8vWSQRToRG9Cgafks5twyZpgaJpZM4LiXly
.

[Vampire]

@sebersole relocation is included, it's the only thing included in distributionManagement currently.

[sebersole]

Yep, just saw that https://docs.gradle.org/nightly/dsl/org.gradle.api.publish.maven.MavenPomDistributionManagement.html#org.gradle.api.publish.maven.MavenPomDistributionManagement:relocation(org.gradle.api.Action)

[Vampire]

@marcphilipp one other question, is it expected that you cannot use dsl-method-like syntax?
You cannot use pom { name 'foo' }, but you have to use pom { name = 'foo' }.

[oehme]

Yes, we didn't add the =-less syntax to the Provider API. From my perspective we shouldn't add it and rather remove it from the old APIs in the long term, since it's one more of those things where you can do things in different ways for no good reason :)

[Vampire]

Well, it's for readability sometimes. :-)