We forward errors from the spawned server to stderr, so we are
already using stderr and this should save someone some pain
vs. just swallowing the fail.
The defaults here are copied from Activator which
in turn are probably copied from somewhere else.
They are of course basically arbitrary, but the
JVM's defaults if we don't set memory options
are insufficient to run most apps.
If the user sets any memory options in the configuration,
we completely leave them alone and don't set any of
our own. So it's always possible to override.
Previously we exited immediately without waiting to get any
error output.
This patch also adds the command line and directory to the
exception message on failure, in case the failure is due to
getting one of those wrong, for example.
Add scala 2.11 test/build verification.
* Add 2.11 build configuratoin to travis ci
* Create command which runs `safe` unit tests
* Create command to test the scala 2.11 build
* Update scalacheck to 1.11.4
* Update specs2 to 2.3.11
* Fix various 2.11/deprecation removals
and other changes.
Fix eval test failure in scala 2.11 with XML not existing.
It turns out windows blocks until a process is finished when
you try to close the stderr handle, but not stdout. Therefore,
we leave stderr open when we shut down, which lets the server
continue to run on windows.
* Add new ServerMain interface
* AppProvider can now choose to load ServerMain or AppMain classes
* Explicitly document what happens if something doesn't match an
expected interface
* Improve error message on inability to load something.
* Parse new [server] section that denotes a service and is lock file
* Ability to serialize launch configurations.
* Attempt to look for active listening server via the lock file
* Forks the launcher itself to run servers from serialized launch configuration.
* Testing echo server.
* Tests to detect basic server functionality will work.
* Revamp all the documentation for the launcher, giving it its own section.
* Full documentation on launcher configuration files.
Revamp launcher documentation to be a bit more in-depth, and split bits into sections.
This entailed modifying ResolutionCache and the CustomPomParser
to reflect changes to the ResolutionCacheManager interface and
DefaultExtendsDescriptor class between Ivy 2.3.0-rc1 and
2.3.0-rc2. Specifically,
1. ResolutionCacheManager now includes two additional methods
that needed implementations in ResolutionCache:
getResolvedModuleDescriptor(mrid: ModuleRevisionId) and
saveResolvedModuleDescriptor(md: ModuleDescriptor). I adapted
the implementations for these (which are expressed primarily in
terms of other interface methods) from Ivy 2.3.0's
DefaultResolutionCacheManager.
2. Instead of taking a ModuleRevisionIdentifier and a resolved
ModuleRevisionIdentifier as its first two arguments, the
DefaultExtendsDescriptor constructor now takes a
ModuleDescriptor. This was a trivial change.
Note that ResolutionCache.getResolvedModuleDescriptor does not
appear to be used by Ivy as sbt uses Ivy and there is thus no
test coverage for its implementation. Also note that the
DefaultResolutionCacheManager object created in
Update.configureResolutionCache now requires a reference to an
IvySettings object; DRCM expects this to be non-null.
* 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.
Jean-Rémi Desjardins
Eugene Yokota
Ben McCann
Havoc Pennington
Roberto Tyley
Jacek Laskowski
Josh Suereth
Dan Sanduleac
William Benton
James Roper
Mark Harrah
Marko Elezovic
Grzegorz Kossakowski