If the user runs foo/runMain in a project with multiple main classes,
sbt will still warn the user about their being multiple main classes
even though this is a pointless warning since the user either is running
runMain which requires a main class. The run task is also excluded since
by default it prompts the user with a main class selector. The previous
logic for doing this filtering was bad because it only looked at the
first command in a sequence and couldn't handle the foo/runMain case
since it was looking for an exact match with `run` or `runMain`. This
commit relaxes those restrictions to look at all of the strings in the
command as well as splitting the string to check if the last part of the
key ends in run or runMain. This logic could theoretically be incorrect
if the user wrote an input task that was expecting run or runMain as
user input but even in that case the only consequence would be that they
wouldn't see the multiple main class warning which generally isn't all
the helpful unless you are packaging a jar that expects there to be only
one main class. It seems unlikely that that the user would be running a
custom input task that is both packaging a jar and expecting run or
runMain as input strings.
Fixes#6430.
What is the problem?
As detailed in #6430, the @nowarn annotation was not suppressing
warnings, even after the first attempt to fix this in PR#6431.
This first PR fixed the problem for projects using
enablePlugins(SbtPlugin), but not for those using sbtPlugin := true.
Why is this a valuable problem to solve?
The annotation was not working as users would expect.
What is this solution?
I have moved the scalacOptions change from SbtPlugin.projectSettings
to the scalacOptions in the JvmPlugin settings.
Has this been tested?
Yes, a test has been added. Also, this branch was tested successfully
on the twinagle repo (https://github.com/soundcloud/twinagle/pull/224).
Ref #377
Apply the dotted-prerelease tag to SemComparator
"A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version."
What is the problem?
sbt/sbt#6496 identifies a bug in the logic which assesses whether
different versions of the same transitive dependency are binary
compatible. If one of the transitive dependencies included a version
with a full-stop literal, it would be parsed incorrectly and an error
would be thrown to the user falsely saying that the dependencies are
binary incompatible.
What is the solution?
This PR fixes the regex used by the parser to include full-stop literals.
Is there anything else to be done?
It is worth us checking the rest of the codebase in case this bug might
exist in other parsers. The tests are super helpful for figuring out
which strings might break the current logic.
Samuel CLARENC
Eugene Yokota
Adrien Piquerez
dependabot[bot]
Peter Janssen
Ethan Atkins
Matthias Kurz
Filip Zybała
Amina Adewusi
Brice Jaglin