Releasing a scala library

Question
1

I’m reading through the document LIBRARY AUTHOR GUIDE, in particular section Create a Sonatype Account and Project where it explains that I need to create a Sonatype account and create a “new project ticket”. The section indicates that this latter step will allow me “define the groupId that you will release to”.

I created a Sonatype account, and created a new project ticket, at least I think I did. But it never asked me for a project name nor a groupId.

Can anyone explain what I need to do to “create a new project ticket”?

2

I have no experience at all with publishing a library to the general public. Just as a note, if you don’t actually want to share your library with others, but only want to use it in other projects locally, you could perhaps just make do with sbt publishLocal.

1 Like
3

Thanks for the suggestion. If I don’t have success with the publication, I may try your suggestion.
The problem with publishing locally is that if I distribute my code to anyone else (publicly or privately) they’d be missing that local dependency, if I understand correctly.

4

I think this is an example of a “new project ticket”. Did you create one of those?

5

This is what I created. I didn’t see options for group id, project url, etc.

6

Yes, correct. They’d need the source project for the library, too, and have to publish locally themselves.

7

Regarding the Sonatype account and groupId, you should find everything you need on this documentation page from Sonatype. It’s necessary if you want to publish to the Maven Central repository, which is pretty much the standard for publishing open source libraries for Scala (and Java).

You can also set up your own Maven (or Ivy) repository (publicly accessible or not), either setting it up yourself or using a service such as https://bintray.com (as an example, there are of course others). But anyone who wants to use your library will need to configure a custom repository in their build file, and they won’t have any guarantee that it will still be available in a few years… So using Maven Central makes a lot more sense for open source libraries, if you want other people to be able to use them.

8

I’ve published my project locally. And I indeed see that it has been installed in ~/.ivy2/local/fr.epita.lrde/clcompat_2.13/0.1
What do I need to do in a project where I wish to reference this?

In the build.sbt file I’ve added

libraryDependencies += "fr.epita.lrde" %% "clcompat" % "0.1"

But I need to import something in the scala code. What do I need to import?

9

But I need to import something in the scala code. What do I need to import?

WDYM?

You need to import your classes like with any other library.

10

Oh I see. Thanks. I was trying to incorporate the fr.epita.lrde prefix which seems to be unnecessary.

import cl.CLcompat._

seems to work correctly, just as if the package were defined within the same project. I was expecting packages defined in different projects to need a prefix.

11

No, everything in the class path works like if they were in the same *JAR.

That is the reason why you should be careful with your packages names.
And that is why java libs tend to have long package names.

1 Like
12

What is .ivy2 ? is this an IntelliJ thing, or Scala thing, or Java thing?
For example, will I be able to publish Clojure projects there as well to be able to call Clojure functions from Scala and vice versa?

13

i just want to point out that many people have difficulty publishing. This is the only reason many have actually succeeded. https://github.com/olafurpg/sbt-ci-release

1 Like
14

None of the above, really – it’s an open-source dependency manager that the Scala stack tends to use. Details here, but you can usually ignore it, since it’s down under the hood.

1 Like
15

It’s a bit easier to use binary for publishing (especially when you want to publish automatically on the CI), using the sbt-bintray plugin; instructions here: https://github.com/sbt/sbt-bintray#install

Alternatively, if you have your code on GitHub, you could also use jitpack which requires no account since it builds your project out of the sources on the first use.

16

Indeed, the easiest way to share code is with jitpack.

The next easiest way is with Bintray. However you don’t need sbt-bintray. Just copy https://github.com/nafg/slick-additions/blob/master/bintray.sbt to your project (or its contents to build.sbt.)
You need to create a new maven Package on bintray.com. Update the publishTo setting accordingly. And set the BINTRAYKEY environment variable to your Bintray API key (accessible when you go to Edit Profile). Then just sbt publish.

1 Like
17

But keep in mind that publishing using that plugin is a two stage process, which is what you want when cross publishing your library so you don’t end up with a half published version.

18

Not sure what you mean. By default after running publish I still have to log into Bintray and click to actually release the binaries. You can append ;publish=1 to the publish URL to avoid this. I’m not sure what you mean by half-published version though?

Note that I use this approach on a number of cross-published libraries (see https://github.com/nafg?tab=repositories&q=&type=source&language=scala / https://bintray.com/naftoligug/maven/ if you’re curious)

19

By half published I mean that you end up with a release for only a subset of the Scala versions you wanted to release for because there was some error during uploading the artefacts.

I want to release automatically, and do not want to think about it afterwards. I use sbt +publish +bintrayRelease on the CI.

20

Oops, I’ve discovered a problem with locally published libraries. They don’t work in CI/CD pipelines, as the local library is not installed in the docker image :frowning: