Previously, publishSigned task took a long time if you have hundreds of small artifact files in your projects. By using a local staging repository and bundle upload to Sonatype, thousands of files can be uploaded in several minutes. This will reduce the pain of maintaining cross-build projects that might have multiple sub-modules.
With sbt-sonatype 3.6, you only need two commands to publish your artifacts to Maven Central (Sonatype OSS repository):
publishSigned
sonatypeBundleRelease
sbt-sonatype 3.6 also added support for restarting your release from scratch by properly cleaning up the previously created stating repository at Sonatype. So even if your release fails for some reasons (e.g., network failures or outage of Sonatype API), you can safely restart the release process just by re-running sonatypeBundleRelease command.
Does this mean that you could run publishSigned from several different SBT processes and then run one sonatypeBundleRelease at the end? That would be really great for projects that need to publish for multiple versions of scala.js!
For multi-module and cross-build projects, sbt-sonatype 3.4 will use the root project’s target/sonatype-staging folder for local staging, and release it to Sonatype at once. You don’t need to run multiple SBT processes.
In projects like ScalaCheck the way to publish the project for multiple scala.js versions is to use an environment variable to control which version of the SBT plugin is used, and then launch SBT multiple times with different environment variables. Here’s a link to the plugin.sbt file that controls this.
This means that to do a ScalaCheck release I currently have to run SBT multiple times with different environment variables (e.g. SCALAJS_VERSION=0.6.28), and then manually use the Sonatype interface to finish the process. Could I use sonatypeBundleRelease to do this last step instead?
Thanks. If it’s possible to consolidate all of your artifacts into a single local staging repository after running multiple SBT tasks, sonatypeBundleRelease can be used as the last step.
The bundle upload mechanism itself has been available in Sonatype since more than 5 years ago, and it has been used by many Maven users. Unfortunately, however, nobody in Scala community could connect these dots to sbt until pshirshov mentioned that approach in sbt and sbt-sonatype GitHub issues. Initially, I didn’t fully understand why this approach can be so fast.
I was somehow forced to work on sbt-sonatype because the performance of Sonatype API is becoming quite slow; some projects that could be released in 10 minutes a year ago takes 1 hour or more recently. I was quite reluctant to work on this 4-year old code of sbt-sonatype, but to mitigate the pain I added sonatypePrepare task to make the release cycle retryable, and shipped sbt-sonatype 3.0.
Aha! moment came later. After checking some existing GitHub tickets, I noticed the idea of Pshirshov again and tried to understand how it works by looking at the code of his Ant script.
The bundle upload code was surprisingly simple! So I’ve released sbt-sonatype 3.1 with the bundle upload support in a day. (The current version is sbt-sonatype 3.6, which fixes several minor bugs)
It seems more than 4K+ projects are using sbt-sonatype: https://github.com/search?q=sbt-sonatype&type=Code. I think this new release of sbt-sonatype will save a lot of time for these Scala developers.
