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/
This commit introduces a new "static" launcher that does not use Ivy to
gather all the artifacts that it requires, but rather expect them to be
immediately available.
To be able to use sbt without Internet access, we add a new
`ComponentCompiler` that is able to retrieve the bridge sources from the
resources on classpath and compile it.
Some scripted tests override the default local repository, which
produces errors with the compiler because sbt cannot find the sources
for the compiler interface.
This fix proposes to publish the compiler interface sources to an
alternate local repository before running the scripted tests. This
alternate repository is added to the scripted sbt's configuration, so
that sbt is finally able to find the compiler interface sources.
This commit introduces a mechanism that allows sbt to find the most
specific version of the compiler interface sources that exists using
Ivy.
For instance, when asked for a compiler interface for Scala 2.11.8-M2,
sbt will look for sources for:
- 2.11.8-M2 ;
- 2.11.8 ;
- 2.11 ;
- the default sources.
This commit also modifies the build definition by removing the
precompiled projects and configuring the compiler-interface project so
that it publishes its source artifacts in a Maven-friendly format.
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.
This is mostly for IntelliJ IDEA.
Currently IntelliJ IDEA's Scala (and SBT) plugin defines:
* the project name (as seen in the window title and in the "open recent
project" list) from `name`
* the root module (as seen in the project view and in project structure)
from `id`
* doesn't use `moduleName` at all
After this change the sbt project is no longer identified as "root".
I was undecided between `sbtRoot` and `sbtRootProj`, and went with the
shorter option. I'm happy to revise this decision.
* 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.
Eugene Yokota
Dale Wijnand
Martin Duhem
Grzegorz Kossakowski
fkorotkov
Josh Suereth
Pierre DAL-PRA
Stu Hood