* Deprecate old mainClass method on appProvider
* Create entryPoint method which represnets class used to launch instead.
* Create PlainApplication to wrap static `main` methods. Can return
either Int, Exit or Unit.
* Detect supported 'plain' classes via reflection.
* Add new unit tests appropriate to the feature.
Specify an Ivy resolver with ", descriptorOptional" to make Ivy
descriptor files optional for that repository or with
", skipConsistencyCheck" to disable Ivy consistency checks for
that repository.
The startup script should set sbt.cygwin=true if running from cygwin.
This will set the terminal type properly for JLine if not already set.
If sbt.cygwin=false or unset and os.name includes "windows", JAnsi is
downloaded by the launcher and installed on standard out/err.
The value for jline.terminal is transformed from explicit jline.X to
the basic types "windows", "unix", or "none". Now that sbt uses JLine
2.0, these types are understood by both sbt's JLine and Scala's.
Older Scala versions shaded the classes but not the terminal property
so both couldn't be configured with a class name at the same time.
Lanucher configuration parser would previously require a default
value in variable substitution pattern to be non-empty string.
This is an unnecessary restriction as empty value is sometimes
useful as in this example:
resources: ${sbt.extraClasspath-}
This commit lifts this restriction so empty default values are
allowed. The change has been discussed with @harrah.
Construction of Scala providers was already properly synchronized jvm and machine-wide.
The cache on top of construction was not and neither was the newer ClassLoaderCache.
This could cause the same Scala version to be loaded in multiple class loaders, taking
up more permgen space and possibly decreasing performance due to less effective jit.
The issue is very rare in practice for 0.13 because of the low probability of contention
on ClassLoaderCache. This is because the work for a cache miss is mainly the construction
of a URLClassLoader. In 0.12, however, the work potentially involved network access and
class loading (not just class loader construction), thus greatly increasing the probability
of contention and thus duplicate work (i.e. class loader construction).
When there is contention, multiple class loaders are constructed and then preserved by the
scalaInstance task in each project throughout the first task execution. Only when multiple
scalaInstance tasks execute simultaneously and only during the first execution does this occur.
(Technically, it could still happen later, but it doesn't in practice.)
This means that the number of duplicate class loaders should quickly saturate instead of growing
linearly with the number of projects. It also means that the impact depends on the exact
tree structure of projects. A linear chain of dependencies will be unaffected, but a build with
independent leaves may be limited by the number of cores. The number of cores affects
the number of threads typically used by the task engine, which limits the number of concurrently
executing scalaInstance tasks.
In summary, this might affect the first, cold compilation of a multi-module project with
independent leaves on a multi-core machine with Scala version different from the version used
for sbt. It might increase the maximum permgen requirements as well as slow the jit compilation
by up to one task execution. Subsequent compilations should be unaffected and the permgen
utilization return to be as expected.
This checks to see if the new `crossVersionedValue` is actually implemented
by an AppID and delegates to the deprecated `crossVersioned` method if
there are any issues. This preserves the binary compatibility from
folks using Launcher interface pre-0.13 and post-0.13.
It is no longer necessary for it to be loaded in a stable class loader
and line reading in the launcher does not require anything more advanced
than java.io.Console.readLine(String).
Scala versions 2.8 and later use the version that goes through JAnsi
and for that it is sufficient to have JNA in a stable loader.
Specifically, when the Scala version for sbt is the same as that for the project being built,
the jars in UpdateReport should be the same as those in ScalaProvider. This is because the
loader will come from the ScalaProvider, which uses jars in the boot directory instead of the
cache. The first part of the fix for #661 checks that loaded classes come from the classpath
and so they need to line up.
* Added appRepositories method to Launcher interface
* Added 'bootOnly' configuration, such that repositories can be used only for boot and not applications.
* Added tests to ensure 'bootOnly' and 'mavenCompatible' behave well
* Updated documentation on launcher to reflect new options.
1. KList[M[_]] now instead of KList[HL <: HList, M[_]]
a. head, tail work properly in this variant
b. disadvantage is that full type not easily transformed to new type constructor
2. AList abstracts on K[L[x]], a higher order type constructor.
A. Instances written for:
a. KList
b. Seq[M[T]] for a fixed T
c. TupleN
d. single values
e. operate on one type constructor when nested
B. Main disadvantage is type inference. It just doesn't happen for K[L[x]].
This is mitigated by AList being used internally and rarely needing to construct a K.
* Puppies may rest easy from the removal of Option.get calls.
* better names for config values
* Added a helper method to avoid any possible code duplication, besides repeated def, val, match and for keywords.
Looking for ways to remove this duplciation ASAP.
* Moved from pattern match to ._1, my most hated member.
when a properties file is not otherwise explicitly specified,
the sbt.version from project/build.properties is used to select
the default properties file to use. This launcher should be able
to launch:
0.7.x
0.10.{0,1}
0.11.{0,1,2,3}
0.12.x
Note that it can only launch the release versions of 0.10 and 0.11
listed above and in particular cannot launch snapshot versions. All
0.12.x versions and 0.7.x versions should be supported, although only
0.7.7 was tested.