Is it possible to turn the commands into tasks?

[jvican]

I'm working on sbt-release-early: https://github.com/scalacenter/sbt-release-early.

It now has built-in support for sbt-bintray and sbt-sonatype. I'm doing some tricks to execute sonatype commands from tasks, and then ensuring that they are not run concurrently (especifically, sonatypeRelease).

However, I wonder, what's the need for commands? Wouldn't it be possible to have sbt-sonatype define tasks that can be executed concurrently? I believe that you may be relying on the sbt state to pass info from one command to the other one, and that may be the blocker. Have you thought about other alternatives?

[xerial]

As I commented in #49, if there is a proper way to define a task that is enabled only at the root project, I'm happy to do so.

[xerial]

I think that is why sbt-release plugin is also using a command instead of a task: https://github.com/sbt/sbt-release/blob/master/src/main/scala/ReleasePlugin.scala#L156

[xerial]

Found a similar FAQ, but a solution seems using a command:
https://stackoverflow.com/questions/25241691/how-to-define-a-task-that-is-called-for-the-root-project-only

Another benefit of using command is we can use it in non-sbt projects. I'm using this command for publishing Java Maven projects after running mvn deploy:

$ sbt "sonatypeReleaseAll org.xerial"

[jvican]

As I commented in #49, if there is a proper way to define a task that is enabled only at the root project, I'm happy to do so.

The only issue with this is that sbt doesn't provide a way to find out whether a project is root or not, not even automate the scoping of some settings if a project meets that criteria. I'm following up on this conversation in #49 (comment) since they seem very untangled.

[xerial]

Maybe giving up the current auto-plugin implementation, and explicitly enabling SontypePlugin in the root repo is a way to turn the current sbt-sonatype functionalities into sbt tasks.

[xerial]

@jvican I've tried to use Tasks instead of commands in #87, but it seems sbt cannot update settings (e.g., publishTo) inside task, so we need to use commands.

[xerial]

@jvican Although it's difficult to use tasks for sonatypePrepare and sonatypeOpen commands, we can change sonatypeRelease or sonatypeReleaseAll into tasks.

This will require a breaking change like asking sbt-sonatype users to add enablePlugins(Sonatype) setting so as not to call sonatypeRelease for all sub modules.

If calling a command from a task is not so tricky and is already solved, I'd like to close this ticket.

[eatkins]

@xerial, looking at the source code, it seems to me that the issue is that you want to update the sbt state in sonatypeOpen? If that is the case, there is an undocumented way for a task to modify the state. If a task returns an instance of StateTransform, it can modify the state like a command. Aggregation may not work correctly though.

Also, it seems like the plugin is storing the state of the sonatype session in the sbt state? Would it be possible to use a mutable attribute key? You could store the sonatype session state in an atomic reference and update it in the tasks. That also might be a way to avoid using a command.

The reason I care about this is twofold:

1. commands don't handle ctrl+c so if sonatype is hanging and I ctrl-c the process it kills sbt
2. commands can't really be composed. I wanted to add sonatypeBundleRelease to a custom release task and couldn't do it.

[eatkins]

Also, not to pile on, but it's confusing that the task keys mirror the command names. intellij will autocomplete sonatypeBundleRelease in a build.sbt file which makes it seem like there is sonatypeBundleRelease task that can be invoked within a different task but this isn't true because of the shadowing.

[xerial]

@eatkins Thanks for the info. Actually sonatypeOpen is left just for the compatibility with existing users.

If we develop sbt-sonatype 4.x, I think we can remove these options and use the StateTransform (or some mutable variables) to pass the staging repository URL to the next tasks.