xerial / sbt-sonatype

A sbt plugin for publishing Scala/Java projects to the Maven central.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Skip one of the project during bundle upload

adamw opened this issue · comments

I've got a multi-module cross-released project (https://github.com/softwaremill/sttp). The root project serves just as an aggregate for other projects, and a jar for this project should not be published. However, I think sonatypeBundleRelease tries to locate the jar anyway and fails.

Details:

For the root project, there's a setting to skip publishing: skip in publish := true

I've also set publishTo := sonatypePublishToBundle.value and then during the release I'm doing:

releaseStepCommandAndRemaining("+publishSigned"),
releaseStepCommand("sonatypeBundleRelease"),

The first command stages all the jars appropriately:

[~/projects/sttp/target/sonatype-staging]$ ls
akka-http-backend-1.6.6                     async-http-client-backend-scalaz-1.6.6      core-1.6.6                                  okhttp-backend-monix-1.6.6
async-http-client-backend-1.6.6             async-http-client-backend-zio-1.6.6         http4s-backend-1.6.6                        play-json-1.6.6
async-http-client-backend-cats-1.6.6        async-http-client-backend-zio-streams-1.6.6 json-common-1.6.6                           prometheus-backend-1.6.6
async-http-client-backend-fs2-1.6.6         brave-backend-1.6.6                         json4s-1.6.6                                scalaz-1.6.6
async-http-client-backend-future-1.6.6      cats-1.6.6                                  monix-1.6.6                                 spray-json-1.6.6
async-http-client-backend-monix-1.6.6       circe-1.6.6                                 okhttp-backend-1.6.6                        zio-1.6.6

However, sonatypeBundleRelease fails due to:

[info] Creating a staging repository in profile com.softwaremill with a description key: [sbt-sonatype] sttp 1.6.6
[info] No staging repository for [sbt-sonatype] sttp 1.6.6 is found
[info] Created successfully: comsoftwaremill-1526
[error] java.io.IOException: Supplied file /Users/adamw/projects/sttp/target/sonatype-staging/sttp-1.6.6 is a not an existing directory!
[error] 	at org.sonatype.spice.zapper.fs.AbstractDirectory.<init>(AbstractDirectory.java:32)
[error] 	at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:68)
[error] 	at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:59)
[error] 	at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:50)
[error] 	at xerial.sbt.NexusRESTService.uploadBundle(NexusClient.scala:189)
[error] 	at xerial.sbt.Sonatype$.$anonfun$sonatypeBundleRelease$1(Sonatype.scala:153)
[error] 	at sbt.Command$.$anonfun$command$2(Command.scala:91)
[error] 	at sbtrelease.ReleasePlugin$autoImport$.$anonfun$releaseStepCommand$2(ReleasePlugin.scala:94)
[error] 	at sbtrelease.ReleasePlugin$autoImport$ReleaseKeys$.filterFailure$1(ReleasePlugin.scala:177)
[error] 	at sbtrelease.ReleasePlugin$autoImport$ReleaseKeys$.$anonfun$releaseCommand$9(ReleasePlugin.scala:195)

Is there a way to tell sbt-sonatype that the jar for a project which has publishing ignored should be skipped?

It looks like the first publishTo is pointing to target/sonatype-staging but this local stging folder is not found in the sonatypeBundleRelease step.

How about setting sonatypeBundleDirectory explicitely like this?
sonatypeBundleDirectory := (ThisBuild / baseDirectory).value / "target" / "sonatype-staging" / s"${name.value}-${version.value}"

If everything is working as expected, publishTo should create a staging artifact into:

  • (root project)/target/sonatype-staging/sttp-1.6.6
  • sonatypeBundleRelease should see this folder and log message will be like
    [info] Uploading bundle .../target/sonatype-staging/sttp-1.6.6 to https://oss.sonatype.org/service/local/staging/deployByRepositoryId/.../
    will be shown

The /Users/adamw/projects/sttp/target/sonatype-staging/ directory (so (root project)/target/sonatype-staging) exists, and cotains sub-directories for every module, which publishes jars (akka-http-backend, core, ...).

However, there are no jars for the sttp project, as publishing is skipped:

lazy val rootProject = (project in file("."))
  .settings(commonSettings: _*)
  .settings(skip in publish := true, name := "sttp")
  .aggregate(rootProjectAggregates: _*)

The rootProjectAggregates are the sub-projects for which sub-directories are created. But, since there are no jars for the sttp project, there's nothing to upload.

Ok. I got it. So you have multiple local staging repositories.

It seems sonatype doesn't support uploading multiple bundles to a remote staging repository, so basically we must have a single local staging repository that aggregates all sub-modules.

Probably it would work:

  • Setting sonatypeBundleDirectory := (ThisBuild / baseDirectory).value / "target" / "sonatype-staging" / s"sttp-${version.value}"
    • Then publishSigned will create only a single folder that collects all artifacts of your sub modules.

Sorry. It seems I misunderstood the original intention.

  • The original question was how to skip staging unnecessary jars.

The basic assumption in sbt-sonatype is uploading a single bundle to a remote staging repository.

It's ok even if the root project has no jar as long as the contents under target/sonatype-staging/sttp-(version)/ folder matches with your sonatype repo http://repo1.maven.org/maven2/[com/softwaremill/sttp/]

So the local staging folder should have the folder structure like:
target/sonatype-staging/sttp-(version)/com/softwaremill/sttp/...

@adamw I'll look at your sttp project whether it's possible to publish all artifacts into a single folder.

@adamw With this setting, publishSinged will create a single staging folder, then you will be ready to use sonatypeBundleRelease:
xerial/sttp@0e5caaa

released sbt-sonatype-3.5 so that you only need to configure publishTo setting.

I've tested it locally and it seems good for creating a single folder for bundling.

@xerial thanks a lot! I think everything worked fine using 3.5 :) the build lasted 34 minutes instead of 3 hours (which was expcetionally long, but it usually took about 1 hour).

That's nice!

Actually creating a local staging repo has its own overhead, but it's worth a wait :)