https://github.com/sbt/sbt/pull/4143 kept failing, and while I was debugging,
I noticed that the target that it was downloading scala-compiler was in
/tmp/... for the remote instance.
This moves the fakeboot to a full path, which should make the build
less susceptible to failure due to random network issues.
Previously we'd get in the build logs:
[error] params cannot be negated, it enables other arguments
and lots of wawrnings.
Now we just get lots of warnings without the non-fatal error message.
This version of Jline fixes three things for Emacs users:
- ANSI colors are now enabled for Emacs.
- Terminal echo is now disabled for Emacs.
- History is enabled for all dump terminals.
This version of Jline fixes three things for Emacs users:
- ANSI colors are now enabled for Emacs.
- Terminal echo is now disabled for Emacs.
- History is enabled for all dump terminals.
* 1.1.x:
Use Java's redirectInput rather than sys.process's connectInput
Re-write toolboxClasspath to use sbt-buildinfo
Cleanup generateToolboxClasspath
Upgrade to sbt-buildinfo 0.8.0
Fix how fullClasspath is defined in TestBuildInfo
delete buildinfo.BuildInfo from sbt main
Conflicts:
project/plugins.sbt
* 1.1.x:
Update mimaPreviousArtifacts/sbt.version
Introduce SBT_GLOBAL_SERVER_DIR env var to override too long paths
Handle very long socket file paths on UNIX
Conflicts:
project/build.properties
This works around the name conflict between sbt.test package and sbt.Keys.test.
1. sbt.test package is renamed to sbt.scriptedtest. This allows 1.0 plugins and builds to use `test` to mean `Keys.test`.
2. To keep binary compatibility for sbt 0.13 scripted, I am adding `sbt.test.ScriptedRunner` and `sbt.test.ScriptedTests` in `scripted-plugin` artifact.
3. Another affected user is Giter8 plugin that uses ScriptedPlugin. Since the intereactions are limited to `sbt.ScriptedPlugin.*`, we should be fine here. - https://github.com/foundweekends/giter8/blob/v0.11.0-M2/plugin/src/main/scala-sbt-1.0/giter8/SBTCompat.scala
There are just too many instances in which sbt's code relies on
the `lastModified`/`setLastModified` semantics, so instead of moving
to `get`/`setModifiedTime`, we use new IO calls that offer the new
timestamp precision, but retain the old semantics.
Previously I was seeing the error upon the first scripted test. I thought it was because Main was somehow not early enough. It might just be because scripted technically runs as part of the build.
Ref sbt/io#110
This is an implementation of `textDocument/definition` request.
Supports types only, and only in case when type is found in Zinc Analysis. When source(s) are found then editor opens potential source(s).
This simple implementation does not use semantic data.
During the processing of `textDocument/didSave`, we will start collecting the location of Analysis files via `lspCollectAnalyses`.
Later on, when the user asked for `textDocument/definition`, sbt server will invoke a Future call to lspDefinition, which direct reads the files to locate the definition of a class.
In addition to TCP, this adds sbt server support for IPC (interprocess communication) using Unix domain socket and Windows named pipe.
The use of Unix domain socket has performance and security benefits.
Using a recursive Source meant that ~ looked into target. If you have
any source generators and use ~ with anything the invokes them, like
~compile, that means that the act of generating sources triggers ~ to
re-execute compile (perhaps only on macOS where the NIO WatchService
just polls, after an initial delay).
Requires sbt/io#78
Fixes#3501
This is the first cut for the Language Server Protocol on top of server that is still work in progress.
With this change, sbt is able to invoke `compile` task on saving files in VS Code.
`.value` inside the if of a regular task is unsafe. The wrapping task
will always execute the value, no matter what the if predicate yields.
This commit adds the infrastructure to lint code for every sbt DSL
macro. It also adds example of neg tests that check that the DSL checks
are in place.
The sbt checks yield error for this specific case because we may want to
explore changing this behaviour in the future. The solutions to this are
straightforward and explained in the error message, that looks like
this:
```
EXPECTED: The evaluation of `fooNeg` happens always inside a regular task.
PROBLEM: `fooNeg` is inside the if expression of a regular task.
Regular tasks always evaluate task inside the bodies of if expressions.
SOLUTION:
1. If you only want to evaluate it when the if predicate is true, use a dynamic task.
2. Otherwise, make the static evaluation explicit by evaluating `fooNeg` outside the if expression.
```
Aside from those solutions, this commit also adds a way to disable any
DSL check by using the new `sbt.unchecked` annotation. This annotation,
similar to `scala.annotation.unchecked` disables compiler output. In our
case, it will disable any task dsl check, making it silent.
Examples of positive checks have also been added.
There have been only two places in `Defaults.scala` where this check has
made compilation fail.
The first one is inside `allDependencies`. To ensure that we still have
static dependencies for `allDependencies`, I have hoisted up the value
invocation outside the if expression. We may want to explore adding a
dynamic task in the future, though. We are doing unnecessary work there.
The second one is inside `update` and is not important because it's not
exposed to the user. We use a `taskDyn`.
This commit adds the first version of the checker that will tell users
if they are doing something wrong.
The first version warns any user that write `.value` inside an if
expression.
As the test integration is not yet working correctly and messages are
swallowed, we have to println to get info from the test.
The previous scalafmt plugin had two problems:
* Caching with Coursier did not work correctly
* It failed after the upgrade to 1.0 in my computer (from a clean fork):
```
[error] (testingProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (runProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (taskProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (stdTaskProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (actionsProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (protocolProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (commandProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (mainSettingsProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (mainProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (sbtProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (scriptedPluginProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] (scriptedSbtProj/compile:scalafmtInc) java.lang.NoClassDefFoundError: Could not initialize class scala.meta.package$
[error] Total time: 19 s, completed May 24, 2017 10:44:56 AM
```
This commit replaces the previous scalafmt integration by the one
created by Lucidsoftware, big shoutout! (/cc @pauldraper)
https://github.com/lucidsoftware/neo-sbt-scalafmt
Some plugins remain commented out, for now.
sbt-doge is no longer needed because a variant of it has been folded
into sbt 1.
For some reason scripted requires src/doc jars of sbt, so switch back to
using `publishAll` rather than `publishLocalBinAll`. :(
Also, the sys.prop change in scripted is to force log4j2 to not use a
thread context classloader, and avoid the following:
ERROR StatusLogger Unable to create custom ContextSelector. Falling back to default.
java.lang.ClassCastException: Cannot cast org.apache.logging.log4j.core.async.AsyncLoggerContextSelector to org.apache.logging.log4j.core.selector.ContextSelector
at java.lang.Class.cast(Class.java:3369)
at org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:201)
at org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:226)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:97)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:58)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:94)
at org.apache.logging.log4j.spi.ThreadContextMapFactory.createThreadContextMap(ThreadContextMapFactory.java:73)
at org.apache.logging.log4j.ThreadContext.init(ThreadContext.java:223)
at org.apache.logging.log4j.ThreadContext.<clinit>(ThreadContext.java:202)
at org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
at org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
at org.apache.logging.log4j.core.lookup.ContextMapLookup.<init>(ContextMapLookup.java:34)
at org.apache.logging.log4j.core.lookup.Interpolator.<init>(Interpolator.java:117)
at org.apache.logging.log4j.core.config.AbstractConfiguration.<init>(AbstractConfiguration.java:125)
at org.apache.logging.log4j.core.config.DefaultConfiguration.<init>(DefaultConfiguration.java:46)
at org.apache.logging.log4j.core.layout.PatternLayout$Builder.build(PatternLayout.java:650)
at org.apache.logging.log4j.core.layout.PatternLayout.createDefaultLayout(PatternLayout.java:487)
at sbt.internal.util.ConsoleAppender.<init>(ConsoleAppender.scala:245)
at sbt.internal.util.ConsoleAppender$.apply(ConsoleAppender.scala:196)
at sbt.internal.util.ConsoleLogger.<init>(ConsoleAppender.scala:42)
at sbt.internal.util.ConsoleLogger$.apply(ConsoleAppender.scala:34)
at sbt.test.ScriptedRunner.run(ScriptedTests.scala:221)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at Scripted$.doScripted(Scripted.scala:125)
at $0483e89d182e9d240274$.$anonfun$scriptedTask$5(build.sbt:301)
This covers the case described in #1361 plus an esoteric case too.
Parsers are initialized when sbt starts and text completions use the
knowledge at that time. If we happen to move a new file that should
influence the behaviour of the tab completion, that file will not be
picked up. Before, since we were throwing an error, the previous case
that would no produce any tab completion would also fail, though the
files are legitimately in the correct place.
Add binary-compatible methods to run scripted tests in parallel using
parallel collections. Parallel collections are not tuned and a default
of 4 cores is used for the `ForkJoinPool`. This can be a matter of
experimentation in the future but for now I prefer to stay with it.
The non-parallel methods are not affected by this change.
The changes to the scripted plugin have not been used, only the sbt
scripted plugin is using `runInParallel`. In the future, this change can
also happen so that plugin authors can benefit from parallel sbt
testing. This is not a priority for me now :)
For some reason using ClasspathDependency doesn't work in sbt 1, while
ClasspathDep[ProjectReference] does. The latter is less specific and
works just as well.
This was already supported in the internal Scripted used by sbt but not
in the ScriptedPlugin. This is fixed by just copy-pasting the modified
parser. We will have to wait for sbt itself to be built using an sbt
with the upgraded ScriptedPlugin to be able to avoid the code duplication.
SbtScalariform is now an AutoPlugin, so its scalariformSettings are
already added to the project. So don't add it again otherwise
`disablePlugins(SbtScalariform)` won't work.
And miscellaneous cleanups.
java.lang.Class#newInstance deprecated since Java 9
http://download.java.net/java/jdk9/docs/api/java/lang/Class.html#newInstance--
```
Deprecated. This method propagates any exception thrown by the nullary constructor, including a checked exception. Use of this method effectively bypasses the compile-time exception checking that would otherwise be performed by the compiler. The Constructor.newInstance method avoids this problem by wrapping any exception thrown by the constructor in a (checked) InvocationTargetException.
The call
clazz.newInstance()
can be replaced by
clazz.getDeclaredConstructor().newInstance()
The latter sequence of calls is inferred to be able to throw the additional exception types InvocationTargetException and NoSuchMethodException. Both of these exception types are subclasses of ReflectiveOperationException.
Creates a new instance of the class represented by this Class object. The class is instantiated as if by a new expression with an empty argument list. The class is initialized if it has not already been initialized.
```
Fixes#2761
With sbt 0.13.13-RC1 rediscovered that the dependency pulled in from
Giter8 was affecting the plugins. To avoid this, this change splits up
the template resolver implementation to another module called
sbt-giter8-resolver, and it will be downloaded using Ivy into
`~/.sbt/0.13/templates/`, and then launched reflectively using Java as
the interface.
This adds `new` command, which helps create a new build definition. The
`new` command is extensible via a mechanism called the template
resolver,
which evaluates the arbitrary arguments passed to the command to find
and run a template.
As a reference implementation [Giter8][g8] is provided as follows:
sbt new eed3si9n/hello.g8
This will run eed3si9n/hello.g8 using Giter8.
[g8]: http://www.foundweekends.org/giter8/
LogManager implementation is modified to use ManagedLogger, which can swap out backing Appenders without re-creating the log instance.
The State was also changed to track `currentCommand: Option[Exec]`. `Exec` knows the origin of the command invocation, and using that we can now send the network-originated events only to the network clients.
Combined together, this implements log splitting between the sbt clients (channels).
Use either:
* -Dsbtio.path / -Dsbtutil.path / -Dsbtlm.path / -Dsbtzinc.path on the
command line, or
* -Dsbtio.path= / sbtutil.path= / sbtlm.path / -Dsbtzinc.path in
project/local.properties
Forward-port of #2338.
Include sbt-ivy-snapshots to launchconfig
Prior to this change, the launchconfig for sbt was generated using
Transform's resource generator so releases would include
`typesafe-ivy-releases` repo, and snapshot releases would include
`typesafe-ivy-snapshots` and `sonatype-snapshots` repos in addition.
This is no longer useful since nightly builds are now published to
`sbt-ivy-snapshots` instead, which is backed by Bintray.
This removes the switching logic, so both `typesafe-ivy-releases` and
`sbt-ivy-snapshots` repos are always included into the launchconfig.
This removes the step of needing to download a launcher just to try the
nightly builds.
Cherry-picked 84cba9669c from branch 0.13 to 1.0.x
Tested manually:
$ grep 'version.*:=' build.sbt
version := "0.13.10-SNAPSHOT",
$ git archive --prefix=sbt-0.13.10-SNAPSHOT/ -o ~/Desktop/sbt-0.13.10-SNAPSHOT.tgz HEAD
$ cd ~/Desktop
$ ls
sbt-0.13.10-SNAPSHOT.tgz
$ tar xfz sbt-0.13.10-SNAPSHOT.tgz
$ cd sbt-0.13.10-SNAPSHOT/
$ sbt info
[info] Loading global plugins from /Users/dnw/.dotfiles/.sbt/0.13/plugins
[info] Loading project definition from /Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/project
[info] Updating {file:/Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/project/}sbt-0-13-10-snapshot-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn] * com.typesafe.sbt:sbt-site:0.8.1 -> 0.8.2
[warn] Run 'evicted' to see detailed eviction warnings
[info] Compiling 12 Scala sources to /Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/project/target/scala-2.10/sbt-0.13/classes...
[info] This is sbt 0.13.9
[info] The current project is {file:/Users/dnw/Desktop/sbt-0.13.10-SNAPSHOT/}sbtRoot 0.13.10-SNAPSHOT
[info] The current project is built against Scala 2.10.6
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin...
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.5
When I went digging into Ivy's code base I discovered that it's been
checking if the repository layout pattern ends with M2_PATTERN to use
maven-metadata.xml, which for sbt would return false since we customize
the mattern -
https://github.com/apache/ant-ivy/blob/2.3.0/src/java/org/apache/ivy/plu
gins/resolver/IBiblioResolver.java#L497-L499
To pass File => Unit callback across the classloader boundary
I am encoding it as a java.util.List[File] by overriding
method.
This was needed since Java didn't allow me to cast
from one classloader to the other.
* Remove launch/* code/tests, as these are in the sbt/launcher project.
* Create a new project which will resolve launcher module from sonatype-snapshots,
and repackage it for the currently building version of sbt.
* Remove ComponentManagerTest which was relying DIRECTLY on launcher classes.
We'll need to reconfigure this shortly to enable the tests again.
Remaining TODOs -
* Update resolvers so people can find the launcher.
* Add ComponentManagerTest back.
* Re-publish the sbt-launch.jar in the location it used to be published.