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).
The problem was that -client was different from --client, which
makes for a confusing user experience. So, this change makes
them the same and re-names -client to --java-client. The value
of this is that hopefully -client and --client being the same
feels more logical to users.
```
[error] (zincLmIntegrationProj / Test / executeTests) java.lang.LinkageError: loader constraint violation in interface itable initialization for class sbt.internal.inc.ZincComponentCompiler$ZincCompilerBridgeProvider: when selecting method 'xsbti.compile.ScalaInstance xsbti.compile.CompilerBridgeProvider.fetchScalaInstance(java.lang.String, xsbti.Logger)' the class loader sbt.internal.SbtInterfaceLoader @1224144a for super interface xsbti.compile.CompilerBridgeProvider, and the class loader sbt.internal.BottomClassLoader @52daa20b of the selected method's class, sbt.internal.inc.ZincComponentCompiler$ZincCompilerBridgeProvider have different Class objects for the type xsbti.Logger used in the signature (xsbti.compile.CompilerBridgeProvider is in unnamed module of loader sbt.internal.SbtInterfaceLoader @1224144a, parent loader sbt.internal.MetaBuildLoader$1 @6f36c2f0; sbt.internal.inc.ZincComponentCompiler$ZincCompilerBridgeProvider is in unnamed module of loader sbt.internal.BottomClassLoader @52daa20b, parent loader sbt.internal.ReverseLookupClassLoader @39b00393)
```
eugene yokota
Adrien Piquerez
dependabot[bot]
Ethan Atkins
Matthias Kurz
Filip Zybała
Amina Adewusi
Brice Jaglin
Regis Desgroppes