Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stable Publishing Plugins #1165

Closed
bmuschko opened this Issue Jan 12, 2017 · 44 comments

Comments

@bmuschko
Copy link
Contributor

bmuschko commented Jan 12, 2017

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

This comment has been minimized.

Copy link
Contributor

sebersole commented Jan 11, 2018

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

This comment has been minimized.

Copy link
Member

eriwen commented Jan 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

sebersole commented Jan 11, 2018

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

This comment has been minimized.

Copy link
Contributor

sebersole commented Jan 11, 2018

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

This comment has been minimized.

Copy link
Member

jjohannes commented Jan 12, 2018

@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

This comment has been minimized.

Copy link
Contributor

sebersole commented Jan 12, 2018

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

This comment has been minimized.

Copy link
Member

jjohannes commented Jan 12, 2018

@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

This comment has been minimized.

Copy link
Contributor

sebersole commented Jan 12, 2018

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

This comment has been minimized.

Copy link
Contributor

sebersole commented Jan 18, 2018

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

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

@oehme oehme changed the title Establish Maven publishing plugin as first-class plugin for publishing to Maven repos Stable Publishing Plugins Apr 4, 2018

@nniesen

This comment has been minimized.

Copy link

nniesen commented Apr 23, 2018

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

@nniesen

This comment has been minimized.

Copy link

nniesen commented Apr 24, 2018

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

This comment has been minimized.

Copy link
Member

marcphilipp commented Apr 26, 2018

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

@hameno

This comment has been minimized.

Copy link

hameno commented May 8, 2018

Does signing work with the new plugins?

@oehme

This comment has been minimized.

Copy link
Member

oehme commented May 8, 2018

@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

This comment has been minimized.

Copy link

hameno commented May 8, 2018

@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

This comment has been minimized.

Copy link

hameno commented May 8, 2018

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

This comment has been minimized.

Copy link
Member

marcphilipp commented May 8, 2018

@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

This comment has been minimized.

Copy link

hameno commented May 8, 2018

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

@sebersole

This comment has been minimized.

Copy link
Contributor

sebersole commented May 8, 2018

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

@nniesen

This comment has been minimized.

Copy link

nniesen commented May 8, 2018

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

@marcphilipp

This comment has been minimized.

Copy link
Member

marcphilipp commented May 8, 2018

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

This comment has been minimized.

Copy link
Contributor

Vampire commented May 8, 2018

@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 #4943 got implemented.

@hameno

This comment has been minimized.

Copy link

hameno commented May 8, 2018

@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

This comment has been minimized.

Copy link

hameno commented May 8, 2018

I'd also like support for mavens settings.xml, especially credentials: #1236

@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented May 8, 2018

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

@sebersole

This comment has been minimized.

Copy link
Contributor

sebersole commented May 8, 2018

@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

This comment has been minimized.

Copy link
Member

marcphilipp commented May 9, 2018

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

This comment has been minimized.

Copy link
Member

oehme commented May 9, 2018

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

@oehme

This comment has been minimized.

Copy link
Member

oehme commented May 9, 2018

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

This comment has been minimized.

Copy link
Contributor

Vampire commented May 9, 2018

@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

This comment has been minimized.

Copy link
Member

oehme commented May 9, 2018

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

@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented May 9, 2018

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

This comment has been minimized.

Copy link
Member

oehme commented May 9, 2018

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

@marcphilipp

This comment has been minimized.

Copy link
Member

marcphilipp commented May 9, 2018

@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented May 9, 2018

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

This comment has been minimized.

Copy link
Member

marcphilipp commented May 9, 2018

@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

This comment has been minimized.

Copy link
Contributor

sebersole commented May 9, 2018

@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented May 9, 2018

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

@Vampire

This comment has been minimized.

Copy link
Contributor

Vampire commented May 9, 2018

@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

This comment has been minimized.

Copy link
Member

oehme commented May 9, 2018

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

This comment has been minimized.

Copy link
Contributor

Vampire commented May 9, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.