Taro L. Saito

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

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...

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.

@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.

@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...

@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...

sonatypeProfileName should be a domain name prefix (e.g., org.xxx, com.github.xxx, etc.)

It has not been changed at all. The user name should be set at Credential https://github.com/xerial/sbt-sonatype#homesbtsbt-version-013-or-10sonatypesbt

It's good to have unless custom Nexus repository is used, which would have no such requirements.

I saw this error when sbt tries to read byte code compiled with Scala 2.13 from Scala 2.12 classes or vice versa. This is because is ScalaSig is Scala-version dependent....