| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
The tests have been updated to check the returned error if the route
file cannot be parsed properly.
|
|
|
|
|
|
| |
This module adds workers specialized for play 2.6.0. and 2.7.0, these
modules actually depend on playframework artifacts. They are dynamically
loaded from the `RoutesCompilerWorkerApi`.
|
|
|
|
|
|
|
|
|
| |
This is the second commit of a redesign of the play lib module.
This module contains only the common `api` which is implemented by the
actual workers. It also defines a specific ADT to configure the type of
routes generator to be used for the project. The ADT feels cleaner than
a simple string but may be too restrictive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit of a redesign of the play lib module. The new
design was massively inspired from the `scalajslib` module.
It adds a specialized worker for each version of play, both workers
implement a common api from an `api`. The main module delegates to a
`loader` which dynamically looks up the bridge instance through
reflection then triggers the generation.
- adds a `RouteCompilerWorkerApi` trait which establishes the bridge to
the actual `RouteCompilerWorker`.
- drops the existing `RouterGeneratorWorker` (it is specialized by
versions of play and extracted to its own submodule).
- updates the `RouterModule` with improved settings and documentation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes https://github.com/lihaoyi/mill/issues/451
|
|
|
|
|
| |
That way, we do not prevent class loader unloading / garbage collection.
Also, we reduce the chance to use an outdated class loader.
|
|
|
|
|
|
| |
Fixes https://github.com/lihaoyi/mill/issues/538
Thanks to Jim Kleckner
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes https://github.com/lihaoyi/mill/issues/535
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* PublishModule: adds gpgKeyName flag
* 1 - Intro to Mill.md: usage sample of publish updates for gpgKeyName
|
| |
|
| |
|
|
|
|
| |
dest/classes and resources dirs are not properly recognized).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* More improvements to ZincWorkerImpl
- Cache classloaders separately from `ScalaInstance`s
- Pre-compute `analysisMap` to speed up lookups
- Allow compile-to-jar using sbt/zinc 1.3.0-m1
* Update build.sc
* Update ZincWorkerModule.scala
* Update ZincWorkerImpl.scala
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow usage of ZincWorkerImpl without hashing files
This is to better support non-Mill build tools like Bazel or Make who might do their own file hashing/mtiming for change-detection
* Update ZincWorkerImpl.scala
* Update ZincWorkerImpl.scala
* Update ZincWorkerImpl.scala
|
|
|
|
| |
"inclusive dot" (#481)
|
| |
|
| |
|
|
|
|
| |
See https://github.com/lihaoyi/mill/issues/477
|
|
|
|
| |
Added Aborted result type.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
policy (#494)
* Avoid unnecessary dependency downloading by providing fetches per cache policy; add ticker logging when they are downloading
* Fix GenIdeaTests by making the Log context Option[]al
* Add some comments
* Rebase and resolve
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Generalize Zinc worker
- Compiler bridges can now be either pre-compiled or on-demand-compiled
- Scala library/compiler jar discovery is now configurable
- Zinc compiler cache is now configurable, rather than being hardcoded at n=1
* .
* update constructor args
* remove duplicate util/AggWrapper.scala file
* fix
* fix
* fix
* cleanup
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Discover - break overridesRoutes into fixed size chunks
* Discover - simplify lambda creation
* add LargeProjectTests
* LargeProjectTests: remove Ydelambdafy
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
* collapse boilerplate folder structure within src/ folders
* .
|
|/ |
|
|
|
|
|
|
|
|
|
| |
This reduces the {scala,scalajs,scalanative}-worker dependency from the entirety of Mill to a much narrower `mill.api` module. This reduces the amount of classpath pollution within these workers, should mean they're much faster to download the first time, and reduces the amount of random junk they would pull in if they were to be used outside of the Mill project.
The interactions between the various *Modules and their *WorkerImpls has been narrowed down to the `*.api` modules, which only depend on other `*.api` modules.
A lot of things have been moved around; user code is unlikely to break, but it's possible some will if it references classes that have been moved around. Forwarders have been left for the few internal classes that Mill uses in it's own `build.sc`, to support bootstrapping. Third-party code which breaks should be a straightforward to fix just by updating imports
The `*.api` modules have minimal dependencies (mostly uPickle and os-lib) and minimal code. There is still a bunch of implementation code in there: some of it defining data-types that are commonly sent across the module/worker interface (`Agg`, `PathRef`, ...), and some of it just general helper functions that are needed both in modules and workers. The latter code isn't strictly API definitions, but for now is small enough it's not worth splitting into it's own module
|
|
|
|
| |
See https://github.com/lihaoyi/mill/issues/502
|