Setting stagingRepositoryId in nexus-staging-plugin

[szpak]

Currently nexus-publish-plugin + nexus-staging-plugin works fine with Travis for one parallel publishing. To speed up the publishing process and make it more bullet proof the closeRepository task could take the (externally set) number instead of looking for one open repository (which always has been a workaround). As a fallback (if not set) it would be still be gathered the old way.

Therefore, I could add setStagingRepositoryId() in CloseRepositoryTask (probably in the super class which I plan to create) to hold that String value. It would be set by nexus-publish-plugin (taking into account that method is not available in the earlier plugin versions, which is quite odd). WDYT? Maybe there is now a better way in Gradle to set that kind of inter-task (or inter-plugin) dependencies/shared value to decrease coupling?

[marcphilipp]

Since this plugin already checks for the presence of nexus-staging-plugin I think that would be a useful addition. Is there an issue with parallel publishing?

[szpak]

nexus-staging-plugin currently has to look for one open staging repository, assuming that the one created by the current build. It makes the whole process fragile as there could be more release build from different projects using the same staging profile. In addition, in a case of failure, somewhere down the line, a repository can be left in an open state and it's required to do a manual clean up (as nexus-staging-plugin cannot distinguish which of those two repositories should be closed and releases).
Having the staging repository number set explicitly makes releasing more reliable.

[marcphilipp]

Understood. Let me know when you've published a version of the staging plugin that supports setting the id. I guess I'll have to use reflection to set it to stay compatible with older versions.

[szpak]

I made required changes. In the plugin extension there is a Groovy property stagingRepositoryId which can be used to set a value from your task to be reused. I had to modernize a part of project configuration to leverage Provider and an ability to access the current value in a plugin extension via a task property/input (conventionMapping was very limited). I plan to modernize also other properties and inputs, but it will be not backward compatible, so I moved it to another version.

Would setting stagingRepositoryId in the plugin extension be sufficient for you?

Regarding reflection concerns I propose to put the newer GNSP version as compileOnly/provided dependency and call the stagingRepositoryId getter in a try..catch block. On NoSuchMethodError (or something) you could just display warning than upgrading GNSP to the newer version (probably named 0.20.0) would improve releasing reliability.

You can play with the snapshot (0.12.1-SNAPSHOT) version I've just uploaded (or Jitpack for branch devel). When confirmed it works fine on your side I will release the new version (once I fix the releasing issue with Travis as I use uploadArchives in my CD infrastructure ;) ).

[marcphilipp]

Thanks, sounds good to me! Not sure when I'll get to it, though. Do you have time to work on a PR?

[szpak]

I took a look at the code and while just setting a value is trivial, putting it together is more complicated. You very nicely encapsulate internal details (such as stagingRepositoryId) in NexusClient which in that particular case (getting those details) complicates the thing. I didn't like to make your code "uglier" with my change, so (unless have a flash of inspiration) I would prefer to leave it to you.

[Vampire]

I have no problem with uglifying foreign code, I made a PR with the needed changes. :-D

[ihostage]

Hi, @marcphilipp! 😉
Do you have a roadmap for release milestone 0.2.0? Maybe the release date is scheduled?

[marcphilipp]

@ihostage I cannot really promise a date but since #16 and #20 are almost ready it will probably be no later than early next week.