| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
`utest.framework.TestPath`
|
| |
|
| |
|
|
|
|
| |
scala versions
|
|
|
| |
fixes #102. Use scala js testing framework to launch tests
|
| |
|
|
|
|
| |
the `build.sc` file
|
| |
|
| |
|
| |
|
|
|
|
| |
isolated module/classloader. Most scalalib test pass, tho GenIdea is still broken
|
|
|
|
|
|
|
|
|
|
|
|
| |
`testLocal` and `runLocal`
- Support passing `forkEnv` parameters to `test` and `run`, necessary to get Ammonite working
- Standardize signatures of `Jvm.interactiveSubprocess`/`Jvm.subprocess`
- `Jvm.inprocess` is now `Jvm.runLocal`
- Swap `TestModule.testLocal` over to using `Jvm.runLocal`, for consistency with everything else
|
|
|
|
| |
Removes a lot of useless folders and gives us a chance to exercise this simplified layout. Support for the SBT layout is still verified by our integration tests
|
| |
|
|
|
|
|
|
| |
- `projectDeps` is now `moduleDeps` for compatibility with our `Module` terminology
- `scalalib.Module` is now `ScalaModule` for compatibility with `import scalalib._`
|
|
|
|
| |
- Update `build.sc`, `build.sbt` and `ci/` scripts
|
|
|
|
|
|
| |
- Update readme and `ci/` scripts to refer to new project layout
- Remove stale `pprint.log`s
|
| |
|
| |
|
|
|
|
| |
things still stubbed out with `???`
|
| |
|
|
|
|
| |
enforce deduplication
|
|
|
|
| |
implement `CrossSbtModule` that works with `scala-2.10/` `scala-2.11/` etc. folders
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* add generated source
* naming
* multiple content root
* no message
* fix output classes path
|
|
|
|
| |
`map`/`flatMap`/`filter` APIs
|
|
|
|
| |
automatically propagates the `ctx` for you
|
|
|
|
|
|
|
|
| |
by propagating implicits throughout the tree of nested `mill.Module`s
This currently adds some annoying boilerplate to the definition of cross/abstract modules, which can probably be removed using Macros.
The `Segments` mapping generated by discovery is still present and used in a few places, though it will be removed
|
|
|
|
|
|
|
|
| |
hierarchy, which each module receives and extends.
One constraint is that now must define your abstract modules as `trait`s rather than `class`es, or otherwise add an implicit `ctx: ModuleCtx` parameter to your class definition.
So far this lets us remove some explicit `basePath` definitions in `build.sc`. Proper handling of `basePath` in `CrossModule`s is future work
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Those tests now download a snapshot of the relevant git repo rather than vendoring the files, and use a bare `build.sc` instead of having the build object be included in the test classpath.
Tests pass using `sbt integration/test`, but `mill integration.test` still doesn't work
|
|
|
|
| |
`T.source` to behave as before but `T.input` can be used for other things. Fixes https://github.com/lihaoyi/mill/issues/77
|
|
|
|
|
|
| |
- Prepare `T.ctx().base: Path` that `Task`s (including `T.source`) can use to find a "default" path for source files.
- Simplify `Cacher`
|
|
|
|
|
|
|
|
| |
`ScalaPlugin` -> `scalalib`, to avoid confusion with Scala compiler plugins
`ScalaModule` -> `module`, to be used via `scalalib.Module`, avoid unnecessary duplication in th name prefix
`plugin` -> `moduledefs`, to more accurately describe what it does (since it includes `Cacher` as well)
|
|
|
|
| |
paths, to fix https://github.com/lihaoyi/mill/issues/86
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
duplication
DRY it up internally
Move the Bridge downloading logic into `shared.sc` as well, and swap the subprocesses for in-memory processing using scalaj-http and ZipInputStream
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove method defns for zipMap/zip that will be generated.
The trait Applyer will now extend from ApplyerGenerated which will contain the code-generated definitions.
* Script to generate code for Applicative
* Generate the zip methods in Target
* Generate zip methods in ApplicativeTests
* Make sure the full 22-arities are generated
* Move code generator into build.sc.
Remove generate.sc from directories where code will be generated.
* Generate code as part of the SBT also
* Properly wire up the test sources
* Generate all the code in one place
|
|
|
|
|
|
|
|
| |
dependencies between `Ctx` -> `Discovered` -> `Task`
- `mill idea` works now using `GenIdea` as a standalone `T.command` making use of the new contextually-available `Mapping`
- Limit implicit `ReplApplyHandler` to `--repl` only, to avoid it kicking in if `build.sc` scripts are screwed up and adding further confusion
|
|
|
|
| |
Tasks, for usage within `GenIdea` and similar
|
| |
|
|
|
|
|
|
| |
master branch
Remove the `out/run.sc` entrypoint script, using Ammonite's new `codeWrapper` API to synthesize the necessary wrapper/forwarder objects to substitute it
|
|
|
|
| |
now you can publish your module with `mill run MyModule.publish --credentials $SONATYPE_CREDENTIALS --gpgPassphrase $GPG_PASSPHRASE`
|
| |
|
|
|
|
|
|
|
|
| |
implementations, added a `Task.sequence` that does what `traverse` used to do
- Added a `test.sh` script to easily kick off self-hosted unit test runs
- Tweak `ScalaModule` to fall back to the old behavior of including the transitive classpath during compilation
|
|
|
|
| |
Move `assembly`/`releaseAssembly` targets out of the stub `ScalaModule`, to take advantage of the new top-level `Target` support
|