| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
`codeWrapper` to inherit from `mill.Module`
|
| |
|
|
|
|
|
|
|
|
| |
keyword when overriding a field within a `mill.Module`
This only applies to `mill.Module`s, not overrides elsewhere which still require the keyword. `mill.Module`s tend to have lots and lots of overriding, so the keyword is basically noise.
Also includes the necessary build changes to enable the locally-built Scalac plugin when compiling the test suite. Note that no changes are necessary for the executable assembly, because the `scalac-plugin.xml` will be included in the assembly and get picked up by the Ammonite scalac plugin classloader automatically
|
| |
|
|
|
|
|
|
| |
* Resolve compiler bridge jar
* Create a release artifact
|
|
|
|
|
|
| |
default source/test locations for builds using SBT project layout
Also split out plain-old-Scala-logic in `Lib` from inheritable traits in `ScalaModule`, since `ScalaModule` was getting a bit unwieldy
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
into Mill as JVM properties.
This makes the dependency between the compiler-bridge jar and the Mill executable explicit, allowing us to swap out the locations compiler-bridge jars (which end up in different places, depending on whether you're building with SBT or Mill) or eventually making them load from Maven Central in a "release" Mill executable
Since Mill (and uTest) both do not support SBT-style test arguments, we need to use `forkTest` instead of `test` to run the Mill tests passing the compiler-jar locations as JVM props. This necessitated some fixes to make `forkTest` behave properly
|
|
|
|
|
|
|
|
|
|
| |
cross-minor-version `AcyclicTests` running using the `mill` test runner
Fixed `Discovered` to only pick up public `Target`s, which makes it skip things like the `super$compile` of an overriden `compile` target.
Split up `sources` and `allSources`
TBD how to properly switch the `compilerBridgeJar` between the different output paths of SBT's compile-dir and Mill's compile-dir, and eventually to a maven-central artifact too
|
|
|
| |
This allows an easy way to hook an external debugger via -agentlib. JAVA_OPTS is picked up by both Scala and Sbt, so it seems an easy win.
|
| |
|
| |
|
|
|
|
| |
Also workaround a few scala-reflect bugs in `Discovered` and `Router` that were making this not-work
|
| |
|
|
|
|
| |
shelling out to `chmod`
|
| |
|
|
|
|
|
|
| |
Added a `TaskModule` subclass of `Module`, which delegates to a `self` task that you can run directly from bash
Fixed `GenIdea` to fix reversing of module path in generating module name
|
|
|
|
| |
Fixed `GenIdea` to fix reversing of module path in generating module name
|
|
|
|
|
|
|
|
| |
Try out the following commands on our Mill `build.sc` file to exercise this functionality
- `scalaplugin/target/mill run Core.cross[jarA].jar`
- `scalaplugin/target/mill run Core.cross[jarB].jar`
- `scalaplugin/target/mill run Core.cross[jarC].jar`
|
| |
|
|
|
|
|
|
| |
Can be tested out on our `build.sc` via `scalaplugin/target/mill run Core.cross[a].printIt`
Needs tons of cleanup...
|
| |
|
| |
|
|
|
|
| |
scala sdk
|
|
|
|
| |
used metacircularly
|
|
|
|
| |
scalaplugin/assembly && amm build.sc idea`
|
| |
|
| |
|
|
|
|
| |
`amm -w` watch-n-rebuild functionality working on `build.sc`
|
| |
|
| |
|