Poorly documented use of sonatypePublishTo with subprojects

[Kuroshii]

Original issue

Use Case

Working on a project that has multiple subprojects and an empty root project used only for aggregation, I wanted to write a simple release procedure that would publish all of the subproject artifacts in one staging repository, and then release that repository. Because sonatypeRelease won't work when there are several staging repositories open, I opted for an "open, publish, release" flow.

Initial Attempt Based on Documentation

I had a simple script setup like this, called checkPublish to run after every build.

if [ $BRANCH == 'master' ]; then
    echo Publishing to Sonatype
    sbt 'sonatypeOpen "Release via Travis ($TRAVIS_BUILD_NUMBER)"' publishSigned sonatypeRelease
fi

In the settings shared by subprojects, I set publishTo := sonatypePublishTo.value, following the README to my best understanding.

Problem

However, this didn't work as expected. sonatypeOpen and sonatypeRelease did give normal looking logs, and publishSigned did run successfully, just nothing was released.

I ended up looking into the plugin's implementation for a while before I saw the cause of this problem.

The problem in this case is that sonatypeOpen and sonatypeRelease are implemented as commands, meaning they only change settings at the root level, and thus the value of sonatypePublishTo was only updated in the root project, which appears to do nothing in my use case.

Solution

In my top-level build.sbt, I set publishTo in ThisBuild := sonatypePublishTo.value, so that publishTo in subprojects inherits the value of sonatypePublishTo from the parent project.

Feedback / Recommendations

• Since the README lists publishTo := sonatypePublishTo.value as a configuration, with no other commentary, it's not obvious that that configuration might not be correct in some cases. I would recommend adding some kind of qualification to the README so users know that this might be something to think about.

• It was not obvious to me that the sbt-sonatype plugin could fail in this way, since sonatypeOpen could be implemented as a file-cached task or cached over subprojects using a scope filter.

• To the prior point, I do concede that the documentation does state that sonatypeOpen, sonatypeClose, etc. are "commands". Still, I don't think many people are very acquainted with the distinction and consequences of using a command over a task.

[xerial]

Thanks for the report. Previoius verisions of sbt didn't allow running a task only for the root project, so I needed to use sbt command to run sonatype calls only once for the project.

Now that sbt can enable/disable plugins for each project, we should implement sonatypeXXX commands as tasks as mentioned in #48

And personally speaking I'm not publishing sub modules to different places, so the support for multiple projects needs to rely on external contributions. The current documentation might have several flaws as you pointed out.

I think it's good timing to start working on #48.

[fmv1992]

Indeed. I just had a lot of problems to make the tutorial on readme.md work for a multi project setting.

[xerial]

sbt-sonatype 3.0 has improved the support for releasing multi-module projects using a single staging repository. https://github.com/xerial/sbt-sonatype#uploading-artifacts-in-parallel