mirror of https://github.com/sbt/sbt.git
62 lines
3.7 KiB
Plaintext
62 lines
3.7 KiB
Plaintext
Issues moving Launcher to 2.8:
|
|
creating an Array requires a Manifest, which brings in 40k of classes in scala.reflect
|
|
scala.package$ is 3k (import scala.collection.immutable.List) and brings in scala.xml
|
|
RichInt 2k. scala.collection.mutable.StringBuilder.ensureCapacity uses it (max), which is needed for string concat
|
|
scala.xml brings in 50k of classes
|
|
scala.math brought in 30k, can't remove because RichInt apparently uses it
|
|
100k additional size adds 50ms to startup time (on my faster machine)
|
|
difference between classpaths a) just launcher jar b) current directory + launcher jar is that b) is 50 ms slower than a)
|
|
was able to return to old size by enabling optimize/obfuscate phases of ProGuard
|
|
|
|
- script tasks (in 'scripts' branch). To use:
|
|
1) add implementation of jsr223 to project/build/lib, declare in project/plugins, or add to sbt startup classpath
|
|
2) Mix sbt.scripts.Scripts into your project definition
|
|
3) Create project/scripts/name.ext
|
|
4) Run as 'name'
|
|
5) To work with dependencies, get the task from the scriptedTasks map by name. Ex:
|
|
lazy val myTask = task { ... } dependsOn scriptedTasks("myscript").
|
|
|
|
- added experimental 'sbt-update version [output.jar]' command enabled by mixing in UpdateSbt trait. It probably doesn't work on Windows, but confirmation either way would be helpful.
|
|
Changes 'sbt.version' after verifying the version is valid by downloading that version of sbt.
|
|
Updates the current launcher jar or the location specified in the second argument with either a downloaded sbt-launch-<version>.jar if available or a copy of the current launcher jar that uses <version> by default when starting new projects.
|
|
|
|
TODO:
|
|
- tasks as promises
|
|
- aggressive recompilation
|
|
- API API. Read, write, search API.
|
|
- source build system
|
|
|
|
- launcher interface versioning
|
|
- allow comments in datatype definition file
|
|
- tests for API extractor
|
|
- have background triggered commands (~sync)
|
|
|
|
Task engine
|
|
- method tasks will be normal tasks that pull the command line from a CommandLine task
|
|
- per task configuration, including logging (e.g. 'task compile log debug')
|
|
- unnamed tasks log to parent task
|
|
- better control over parallel logging. Approach undecided. Some possibilities:
|
|
+ optionally one task always logging
|
|
+ log each task to a file
|
|
+ interactive control over logging (might require tasks that use console to be explicit in their dependence on the console)
|
|
|
|
- should be able to connect one preprocessor to another
|
|
|
|
- Interfaces subproject that depends on no other project and defines interfaces in package xsbti. They are written in Java and cannot refer to Scala classes (compileOrder = JavaThenScala). These interfaces can be used to pass objects across ClassLoader boundaries.
|
|
- launcher/main interface is not static (no system properties should be used past the static entry point)
|
|
- simple, well-defined ClassLoaders
|
|
- use Exceptions instead of Option/Either
|
|
- every component gets its own subproject
|
|
- can use any version of compiler/Scala that is source compatible with the compiler-interface component
|
|
- build xsbt using normal cross-build conventions
|
|
- compiler: raw interface (no dependency analysis, but still in same jvm) or with dependency analysis
|
|
- compiler: can specify scala-library.jar and scala-compiler.jar + version instead of retrieving the ClassLoader
|
|
- compiler: new phase that extracts API defined in sources (classes, their members, and all type information)
|
|
- minimal dependence on main xsbt logger from subcomponents: use thin interface for subcomponents
|
|
|
|
Dependency Management
|
|
- resolvers are completely defined in project definition (use Resolver.withDefaultResolvers)
|
|
- configurations completely defined within project (use ModuleConfiguration.configurations)
|
|
|
|
Launcher
|
|
- see launch.specification |