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)
```
Fixes#2835
Somehow the fix in #4033 due to various initialization.
Here's a bit more aggressive rebasing of the base directory
that should fix the `project` and `target` directory created during sbt
new.
JVM powered applications may be given an alternate home by means of the
`user.home` system property, which is handy for managing caches in CI
(the property may be set by different means, including environment
variables such as `JAVA_TOOL_OPTIONS` or `_JAVA_OPTIONS`).
Alas, this doesn't fully work when the `sbt` script downloads the
launcher jar to `$HOME`.
The present change consists in retrieving the value of this property by
means of a `findProperty` function extracted from the existing
`getPreloaded` one (adapted accordingly).
No java process get spawned here.
Tests were failing because of bintray migration. Lightbend forgot
to move dependencies. This fixes it by upgrading to more modern
library dependencies.
eugene yokota
Amina Adewusi
Brice Jaglin
Adrien Piquerez
Regis Desgroppes