-
Notifications
You must be signed in to change notification settings - Fork 949
don't require publishTo specified if publishArtifact is false
#3760
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
don't require publishTo specified if publishArtifact is false
#3760
Conversation
I think this is a good change. Could you add a test for this use case so we don't regress, please? Either to an existing scripted test or a new one. Given this isn't (as far as I understand) a regression in behaviour since sbt 0.13, I think it's safer merge this in 1.x, so it participates in a release candidate phase. |
FWIW If |
d63b2f1
to
991c71d
Compare
|
348b0d3
to
93b18b6
Compare
the travis errors look like flukes. @dwijnand anything else stopping this to get merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Restarted the failed Travis CI jobs. This LGTM, pending Travis CI.
green enough @dwijnand ? |
Even with `publishArtifact := false` the user is still forced to define a (dummy) resolver that's never used, e.g. `publishTo := { Some("publishMeNot" at "https://publish/me/not") }` Otherwise the following error is thrown: ``` publish [error] java.lang.RuntimeException: Repository for publishing is not specified. [error] at scala.sys.package$.error(package.scala:27) [error] at sbt.Classpaths$.$anonfun$getPublishTo$1(Defaults.scala:2436) [error] at scala.Option.getOrElse(Option.scala:121) [error] at sbt.Classpaths$.getPublishTo(Defaults.scala:2436) [error] at sbt.Classpaths$.$anonfun$ivyBaseSettings$48(Defaults.scala:1917) ```
82b2b9e
to
4668faf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay @mpollmeier. Yes.
I added notes as well (and rebased).
will be fixed via sbt/sbt#3760
The description says:
so if I reverse engineer the steps would it be: steps
problem
expectationno errors. Would that be right? |
Your 'reverse engineer' of the problem from back then is correct, and as you said, if |
Even with
publishArtifact := false
the user is still forced to define a (dummy) resolver that's never used, e.g.publishTo := { Some("publishMeNot" at "https://publish/me/not") }
Otherwise the following error is thrown:
Is 1.0.x the right target branch, or should it rather be 1.x?