Open martinkoster opened 3 years ago
Hi Martin. We have single-module and multi-module examples in our e2e tests:
They are used in our cron builds, so should be up-to-date. I hope you will find it useful. If not, please write here about your problems and put a link to your project.
However, that plugin will be no longer maintained in the future.
In addition to that, gradle-nexus-plugin only supports the "maven" plugin (not maven-publish) which is not available anymore in Gradle 7+.
Hi Marcin,
thanks a lot for your quick response. I checked your e2e example and have another question: I can not see an explicit usage of the signing plugin, just the rule, that signing must happen before "initializeSonatypeStagingRepository".
Is your plugin adding a signing task internally? I couldn't find a corresponding output on the console, when I build with Gradle.
Here is a link to my current "build.gradle": https://github.com/martinkoster/actionfx/blob/1.4.0/build.gradle
Publication definition start at line 190.
Currently, I still get a validation error from Nexus side: Missing Signature: '/com/github/martinkoster/actionfx-core/1.4.0/actionfx-core-1.4.0.module.asc' does not exist for 'actionfx-core-1.4.0.module'.
Seems that artifacts are signed, but these "asc" files are missing.
Thanks for any help! Martin
Ok, I found the signing stuff here: https://github.com/gradle-nexus/nexus-publish-e2e-multi-project/blob/master/buildSrc/src/main/kotlin/library-publishing-conventions.gradle.kts
Can't the signing code be part of your main build.gradle.kts? What's the reason to externalize it there?
Can't the signing code be part of your main build.gradle.kts? What's the reason to externalize it there?
Definitely, it can. Here an example from the single-project build: https://github.com/gradle-nexus/nexus-publish-e2e-minimal/blob/4262dc094533721d12c7adee5eacc8573ae9581f/build.gradle#L46-L114
I believe, Marc extracted it to keep the library specific stuff separately, maybe even took it from some his other project. Having multiple projects it might be useful to keep it extracted. For example, in my other projects, I keep it just in gradle/release.gradle
(here, with addition of the CDeliveyBoy plugin, but it is deprecated, so don't think about it too much), but the Marc's approach (in buildSrc
) seems to be more in the Gradle professional way ;).
Thanks a lot for the explanation! I finally made everything working with your new plugin. Thanks a lot for your efforts for the "publish-plugin"!
One thing however remains a mystery to me yet. I was not able to make the signing plugin work, when I directly integrated it in my build.gradle. So, I finally ended up with the same approach than you used in your end-2-end tests (but using Groovy instead of Kotlin).
I have no experience in using this plugin, however, I read somewhere that the signing plugin is only cooperative in multi-module projects, when it is externalized in a separate gradle-file, as Marc did it in the sample end-2-end project. Maybe that was the reason it is not part of the main gradle build process?
Is it planned for the future of your plugin, to integrate the functionality of the "library-publishing-conventions" plugin of your end-2-end tests directly into the "publish-plugin" itself? I think that would help a lot of users and saves a lot of configuration time (I spent now aroud 10 days for making the signing part work. That is btw. not related to your plugin directly, but it seems that the actual signing plugin is a little uncooperative for multi-module projects).
Thanks again for all your efforts!
but using Groovy instead of Kotlin
For me Groovy is still more "natural" to write configuration in Gradle than Kotlin (but Kotlin has better code completion in Idea). However, we have both languages in our e2e-tests as an examples (and PoC).
I read somewhere that the signing plugin is only cooperative in multi-module projects, when it is externalized in a separate gradle-file
Hmm, could you send some link? I would like to read more about that.
to integrate the functionality of the "library-publishing-conventions" plugin
Could you elaborate more on that topic?
Auto signing itself, there is a proposal about auto signing in #85 proposed by @asarkar. However I don't know if he is actively working on that feature.
That is btw. not related to your plugin directly, but it seems that the actual signing plugin is a little uncooperative for multi-module projects).
@marcphilipp Are there any plans to improve that scenario in Gradle itself?
That is btw. not related to your plugin directly, but it seems that the actual signing plugin is a little uncooperative for multi-module projects.
@martinkoster Could you please elaborate?
After spending some hours trying to get things signed I went with ahead with com.vanniktech:gradle-maven-publish-plugin and it works. Sorry, szpak.
Hi,
I am trying to make the gradle-nexus-publish-plugin work with signing in my gradle-multi-module project.
Is there a working example for that? I am stuck and I get different error messages, related to
The current document seems to be only suited for a single-module project. There is also no word about signing.
I am currently trying to migrate to this plugin, but it really gives me a headache.
I used the "https://github.com/Codearte/gradle-nexus-staging-plugin/" plugin in combination with "https://github.com/bmuschko/gradle-nexus-plugin". The latter one did all the signing hustle and uploading to Nexus for me without any problem. However, that plugin will be no longer maintained in the future.
It would be great, if you can point me to some working sample for muti-module-project publishing and signing.
Thanks Martin Koster