All Projects → xerial → Sbt Sonatype

xerial / Sbt Sonatype

Licence: apache-2.0
A sbt plugin for publishing Scala/Java projects to the Maven central.

Programming Languages

scala
5932 projects

Projects that are alternatives of or similar to Sbt Sonatype

sbt-elm
Scala Build Tool (SBT) plugin for the Elm programming language
Stars: ✭ 44 (-83.4%)
Mutual labels:  sbt-plugin
sbt-codeartifact
An sbt plugin for publishing packages to AWS CodeArtifact.
Stars: ✭ 15 (-94.34%)
Mutual labels:  sbt-plugin
grease
CLI utility for managing GitHub releases that comes in handy on CI servers
Stars: ✭ 20 (-92.45%)
Mutual labels:  release-automation
action-snapcraft
🐦 GitHub Action for setting up Snapcraft
Stars: ✭ 34 (-87.17%)
Mutual labels:  release-automation
changie
Automated changelog tool for preparing releases with lots of customization options
Stars: ✭ 180 (-32.08%)
Mutual labels:  release-automation
sbt-hepek
Sbt plugin for rendering Scala objects to files. And more!
Stars: ✭ 17 (-93.58%)
Mutual labels:  sbt-plugin
sbt-kubeyml
Sbt plugin to help deploy Scala applications to Kubernetes
Stars: ✭ 37 (-86.04%)
Mutual labels:  sbt-plugin
sbt-assembly
Deploy über-JARs. Restart processes. (port of codahale/assembly-sbt)
Stars: ✭ 1,801 (+579.62%)
Mutual labels:  sbt-plugin
sbt-jni
SBT Plugin to ease working with JNI
Stars: ✭ 110 (-58.49%)
Mutual labels:  sbt-plugin
sbt-best-practice
Configure common build settings for a Scala project
Stars: ✭ 47 (-82.26%)
Mutual labels:  sbt-plugin
sbt-scala-js-map
A Sbt plugin that configures source mapping for Scala.js projects hosted on Github
Stars: ✭ 30 (-88.68%)
Mutual labels:  sbt-plugin
sbt-ecr
An SBT plugin for managing Docker images within Amazon ECR.
Stars: ✭ 52 (-80.38%)
Mutual labels:  sbt-plugin
sbt-openapi-schema
Generate schema sources for Scala, Java and Elm from an openapi 3.0 spec.
Stars: ✭ 12 (-95.47%)
Mutual labels:  sbt-plugin
github-create-release-action
Create a GitHub release from a Tag
Stars: ✭ 33 (-87.55%)
Mutual labels:  release-automation
sbt-publish-more
📤 Publish artifacts to more than one repository
Stars: ✭ 21 (-92.08%)
Mutual labels:  sbt-plugin
release-downloader
Github action to download release assets from private or public repositories
Stars: ✭ 33 (-87.55%)
Mutual labels:  release-automation
generate-changelog
generates changelog from git based on jira tickets
Stars: ✭ 18 (-93.21%)
Mutual labels:  release-automation
Soteria
Plugin to block compilation when unapproved dependencies are used or code styling does not comply.
Stars: ✭ 36 (-86.42%)
Mutual labels:  sbt-plugin
bump
🌻 CLI tool to draft a GitHub Release for the next semantic version
Stars: ✭ 40 (-84.91%)
Mutual labels:  release-automation
expublish
Automates semantic release versioning and best practices for elixir packages.
Stars: ✭ 17 (-93.58%)
Mutual labels:  release-automation

sbt-sonatype plugin

A sbt plugin for publishing your project to the Maven central repository through the REST API of Sonatype Nexus. Deploying artifacts to Sonatype repository is a requirement for synchronizing your projects to the Maven central repository. sbt-sonatype plugin enables two-step release of your Scala/Java projects.

  • publishSigned (with sbt-pgp plugin)
    • Create GPG signed artifacts to a local staging repository.
    • Make sure adding publishTo := sonatypePublishToBundle.value to your build.sbt
  • sonatypeBundleRelease (New in sbt-sonatype 3.4)
    • This command will prepare a new remote staging repository at Sonatype. If there are exisiting staging repositories that have the same description with sonatypeSessionName key, sbt-sonatype will discard them properly.
    • Then, it will upload the artifacts in the local staging folder to the remote staging repository. Uploading artifacts as a bundle is much faster than uploading each artifact to Sonatype. For example, thousands of files can be uploaded in several minutes with bundle upload.
    • Finally, this command will perform the close and release steps at the Sonatype Nexus repository to verify the Maven central requirements.

After these steps, your project will be synchronized to the Maven central within ten minutes. No longer need to enter the web interface of Sonatype Nexus repository to performe these release steps.

Prerequisites

Configurations

Maven Central

project/plugins.sbt

Import sbt-sonatype plugin and sbt-pgp plugin to use sonatypeBundleRelease and publishSigned commands:

// For sbt 1.x (sbt-sonatype 2.3 or higher)
addSbtPlugin("org.xerial.sbt" % "sbt-sonatype" % "(version)")
addSbtPlugin("com.jsuereth" % "sbt-pgp" % "2.0.1")

// For sbt 0.13.x (upto sbt-sonatype 2.3)
addSbtPlugin("org.xerial.sbt" % "sbt-sonatype" % "(version)")
addSbtPlugin("com.jsuereth" % "sbt-pgp" % "1.0.0")

build.sbt

To use sbt-sonatype, you need to create a bundle of your project artifacts (e.g., .jar, .javadoc, .asc files, etc.) into a local folder specified by sonatypeBundleDirectory. By default, the folder is (project root)/target/sonatype-staging/(version). Add the following publishTo setting to create a local bundle of your project:

publishTo := sonatypePublishToBundle.value

⚠️ Legacy Host

By default, this plugin is configured to use the legacy Sonatype repository oss.sonatype.org. If you created a new account on or after February 2021, add sonatypeCredentialHost settings:

// For all Sonatype accounts created on or after February 2021
ThisBuild / sonatypeCredentialHost := "s01.oss.sonatype.org"

With this setting, publishSigned will create a bundle of your project to the local staging folder. If the project has multiple modules, all of the artifacts will be assembled into the same folder to create a single bundle.

If isSnapshot.value is true (e.g., if the version name contains -SNAPSHOT), publishSigned task will upload files to the Sonatype Snapshots repository without using the local bundle folder.

If necessary, you can tweak several configurations:

// [Optional] The local staging folder name:
sonatypeBundleDirectory := (ThisBuild / baseDirectory).value / target.value.getName / "sonatype-staging" / (ThisBuild / version).value

// [Optional] If you need to manage unique session names by yourself, change this default setting:
sonatypeSessionName := s"[sbt-sonatype] ${name.value} ${version.value}"

// [Optional] Timeout until giving up sonatype close/promote stages. Default is 60 min.
sonatypeTimeoutMillis := 60 * 60 * 1000 

// [If you cannot use bundle upload] Use this setting when you need to uploads artifacts directly to Sonatype
// With this setting, you cannot use sonatypeBundleXXX commands
publishTo := sonatypePublishTo.value

// [If necessary] Settings for using custom Nexus repositories:
sonatypeCredentialHost := "s01.oss.sonatype.org"
sonatypeRepository := "https://s01.oss.sonatype.org/service/local"

$HOME/.sbt/(sbt-version 0.13 or 1.0)/sonatype.sbt

For the authentication to Sonatype API, you need to set your Sonatype account information (user name and password) in the global sbt settings. To protect your password, never include this file within your project.

credentials += Credentials("Sonatype Nexus Repository Manager",
        "oss.sonatype.org",
        "(Sonatype user name)",
        "(Sonatype password)")

(project root)/sonatype.sbt

sbt-sonatype is an auto-plugin, which will automatically configure your build. There are a few settings though that you need to define by yourself:

  • sonatypeProfileName
    • This is your Sonatype acount profile name, e.g. org.xerial. If you do not set this value, it will be the same with the organization value.
  • pomExtra

Example settings:

// Your profile name of the sonatype account. The default is the same with the organization value
sonatypeProfileName := "(your organization. e.g., org.xerial)"

// To sync with Maven central, you need to supply the following information:
publishMavenStyle := true

// Open-source license of your choice
licenses := Seq("APL2" -> url("http://www.apache.org/licenses/LICENSE-2.0.txt"))

// Where is the source code hosted: GitHub or GitLab?
import xerial.sbt.Sonatype._
sonatypeProjectHosting := Some(GitHubHosting("username", "projectName", "[email protected]"))
// or
sonatypeProjectHosting := Some(GitLabHosting("username", "projectName", "[email protected]"))

// or if you want to set these fields manually
homepage := Some(url("https://(your project url)"))
scmInfo := Some(
  ScmInfo(
    url("https://github.com/(account)/(project)"),
    "scm:[email protected]:(account)/(project).git"
  )
)
developers := List(
  Developer(id="(your id)", name="(your name)", email="(your e-mail)", url=url("(your home page)"))
)

Publishing Your Artifact

The basic steps for publishing your artifact to the Central Repository are as follows:

  • publishSigned to deploy your artifact to a local staging repository.
  • sonatypeBundleRelease (since sbt-sonatype 3.4)
    • This command is equivalent to running ; sonatypePrepare; sonatypeBundleUpload; sonatypeRelease.
    • Internally sonatypeRelease will do sonatypeClose and sonatypePromote in one step.
      • sonatypeClose closes your staging repository at Sonatype. This step verifies Maven central sync requirement, GPG-signature, javadoc and source code presence, pom.xml settings, etc.
      • sonatypePromote command verifies the closed repository so that it can be synchronized with Maven central.

Note: If your project version has "SNAPSHOT" suffix, your project will be published to the snapshot repository of Sonatype, and you cannot use sonatypeBundleUpload or sonatypeRelease command.

Commands

Usually, we only need to run sonatypeBundleRelease command in sbt-sonatype:

  • sonatypeBundleRelease
    • This will run a sequence of commands ; sonatypePrepare; sonatypeBundleUpload; sonatypeRelease in one step.
    • You must run publishSigned before this command to create a local staging bundle.

Individual Step Commands

  • sonatypePrepare
    • Drop the exising staging repositories (if exist) and create a new staging repository using sonatypeSessionName as a unique key.
    • This will update sonatypePublishTo setting.
    • For cross-build projects, make sure running this command only once at the beginning of the release process.
      • Usually using sonatypeBundleUpload should be sufficient, but if you need to parallelize artifact uploads, run sonatypeOpen before each upload to reuse the already created stging repository.
  • sonatypeBundleUpload
    • Upload your local staging folder contents to a remote Sonatype repository.
  • sonatypeOpen
    • This command is necessary only when you need to parallelize publishSigned task. For small/medium-size projects, using only sonatypePrepare would work.
    • This opens the existing staging repository using sonatypeSessionName as a unique key. If it doesn't exist, create a new one. It will updatesonatypePublishTo
  • sonatypeRelease (repositoryId)?
    • Close (if needed) and promote a staging repository. After this command, the uploaded artifacts will be synchronized to Maven central.

Batch Operations

  • sonatypeDropAll (sonatypeProfileName)?
    • Drop all staging repositories.
  • sonatypeReleaseAll (sonatypeProfileName)?
    • Close and promote all staging repositories (Useful for cross-building projects)

Other Commmands

  • sonatypeBundleClean
    • Clean a local bundle folder
  • sonatypeClean
    • Clean a remote staging repository which has sonatypeSessionName key.
  • sonatypeStagingProfiles
    • Show the list of staging profiles, which include profileName information.
  • sonatypeLog
    • Show the staging activity logs
  • sonatypeClose
    • Close the open staging repository (= requirement verification)
  • sonatypePromote
    • Promote the closed staging repository (= sync to Maven central)
  • sonatypeDrop
    • Drop an open or closed staging repository

Advanced Build Settings

Sequential Upload Release (Use this for small projects)

> ; publishSigned; sonatypeBundleRelease

For cross-building projects, use + publishSigned:

> ; + publishSigned; sonatypeBundleRelease

Parallelizing Builds When Sharing A Working Folder

When you are sharing a working folder, you can parallelize publishSigned step for each module or for each Scala binary version:

  • Run multiple publishSigned tasks in parallel
  • Finally, run sonatypeBundleRelease

Parallelizing Builds When Not Sharing Any Working Folder

If you are not sharing any working directory (e.g., Travis CI), to parallelize the release process, you need to publish a bundle for each build because Sonatype API only supports uploading one bundle per a staging repository.

Here is an example to parallelize your build for each Scala binary version:

  • Set sonatypeSessionName := "[sbt-sonatype] ${name.value}-${scalaBinaryVersion.value}-${version.value}" to use unique session keys for individual Scala binary versions.
  • For each Scala version, run: sbt ++(Scala version) "; publishSigned; sonatypeBundleRelease"

For sbt-sonatype 2.x:

Using with sbt-release plugin

To perform publishSigned and sonatypeBundleRelease with sbt-release plugin, define your custom release process as follows:

import ReleaseTransformations._

releaseCrossBuild := true // true if you cross-build the project for multiple Scala versions
releaseProcess := Seq[ReleaseStep](
  checkSnapshotDependencies,
  inquireVersions,
  runClean,
  runTest,
  setReleaseVersion,
  commitReleaseVersion,
  tagRelease,
  // For non cross-build projects, use releaseStepCommand("publishSigned")
  releaseStepCommandAndRemaining("+publishSigned"),
  releaseStepCommand("sonatypeBundleRelease"),
  setNextVersion,
  commitNextVersion,
  pushChanges
)

Publishing Maven Projects

If your Maven project (including Gradle, etc.) is already deployed to the staging repository of Sonatype, you can use sbt sonatypeReleaseAll (sonatypeProfileName) command for the synchronization to the Maven central (Since version 0.5.1).

Prepare the following two files:

$HOME/.sbt/(sbt-version 0.13 or 1.0)/plugins/plugins.sbt

addSbtPlugin("org.xerial.sbt" % "sbt-sonatype" % "(version)")

$HOME/.sbt/(sbt-version 0.13 or 1.0)/sonatype.sbt

credentials += Credentials("Sonatype Nexus Repository Manager",
        "oss.sonatype.org",
        "(Sonatype user name)",
        "(Sonatype password)")

Alternatively, the credentials can also be set with the environment variables SONATYPE_USERNAME and SONATYPE_PASSWORD.

Then, run sonatypeReleaseAll command by specifying your sonatypeProfileName. If this is org.xerial, run:

$ sbt "sonatypeReleaseAll org.xerial"
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].