TL;DR
You can now deploy your Scala packages directly from SBT to your packagecloud repositories (including SNAPSHOT
versions)!
Also, we’ve released support for deployment JARs, also known as “fatjars” or “uberjars” to the packagecloud CLI!
Read on to find out how to take advantage of these new features.
Deploying Scala packages from SBT
Thanks to the sbt-aether-deploy plugin, we can tell SBT to use our already existing maven/aether compatible wagon, maven-packagecloud-wagon, to deploy scala packages (even SNAPSHOT
versions) directly from SBT.
To resolve uploaded SNAPSHOT
versions, we use the built-in sbt-maven-resolver-plugin
(as of SBT 0.13.8)
Deploy instructions
The customized setup instructions for deploying Scala packages can be found in the “SBT Deploy” tab of the “Integrations / CI” section of your repository and in our general documentation: SBT Deploy documentation.
Install instructions
Similarly, the customized install instructions are located under the “Install” section of your repository, under the “SBT” tab.
Deploying “fatjars” to packagecloud.io
For JAR uploads that happen outside of a build tool environment, like for example our Web UI, CLI tool, or API endpoint, we use a set of heuristics to automatically detect the right maven coordinates (the groupId
, version
, and artifactId
of a package) for that upload.
However, sometimes there isn’t enough metadata in the JAR package itself to reliably deduce the right coordinates. For these cases, you can supply the coordinates on the CLI by using --coordinates=
with the latest CLI update: package_cloud (0.2.36)
The coordinates take the format of groupId:artifactId:version
, for example:
Alternatively, you can instruct your JAR packaging plugin to include the following entries in your JAR’s MANIFEST.MF
to avoid having to pass coordinates at all:
Implementation-Title
(forartifactId
)Implementation-Vendor
(forgroupId
)Implementation-Version
(forversion
)
Conclusion
Being able to quickly and easily iterate on libraries privately within your organization, regardless if one team is using Scala and the other is using Clojure, can really help move your business forward. Feel free to pop into our Slack Room with any questions or issues you might have.