-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible to turn the commands into tasks? #48
Comments
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. |
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: 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
|
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. |
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 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 If calling a command from a task is not so tricky and is already solved, I'd like to close this ticket. |
@xerial, looking at the source code, it seems to me that the issue is that you want to update the sbt state in 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:
|
Also, not to pile on, but it's confusing that the task keys mirror the command names. intellij will autocomplete |
@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. |
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?
The text was updated successfully, but these errors were encountered: