| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
up mysteriously
|
| |
|
|
| |
__.compile works, haven't run tests yet
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Add tut contrib module
* Add TutModule tests and documentation
* Use Path instead of PathRef for tut target directory
* Use the correct scala version in TutModule
* Ensure resolving tut doesn't bring in extra scala-library jars
* Ensure MILL_VERSION system property is set in tut tests
* Fork to run tut to fix classpath problems, add test with library usage
* Follow convention w.r.t. publishVersion in testArgs
* Add Scaladoc to TutModule
* Don't supply a default version of Tut
* Update docs to account for mandatory tutVersion setting
* Inline tutArgs, otherwise Tut does not recompile when sources change
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
are captured
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#414)
* Upgrade ammonite to 1.1.2-30-53edc31
This is mainly to get https://github.com/lihaoyi/Ammonite/pull/851 which
should reduce the amount of unnecessary work done by incremental
compilation in the Mill build. This requires some code changes since
this means we now depend on a more recent version of coursier, as a
side-effect this means that we do not depend on scalaz anymore.
Also use the same ammonite version in the Mill build and in
ScalaModule#ammoniteReplClasspath.
Also remove an incorrect dependency in the caffeine integration test.
This was always wrong but did not start failing until this commit,
probably due to dependencies appearing in a different order on the
classpath.
* Rename ScalaWorker to ZincWorker
Starting with the next commit, it will be used in Java-only projects
too, so the name is misleading.
* Upgrade to Zinc 1.2.1
* Fix incremental compilation when a Scala project depends on a Java project
Before this commit, JavaModule#compile simply called javac
unconditionally, thus generating new classfiles every time. But if a
Scala project depends on a Java project, this will throw off the
incremental compilation algorithm which will unnecessarily recompile
files. To avoid this we now use Zinc to compile Java projects too (as a
bonus this means that Java compilation becomes incremental). This
required some refactoring in ZincWorkerImpl to be able to compile stuff
without having to pass Scala-specific options.
The issue solved by this commit could be reproduced by running in the
Mill repository:
$ mill main.compile
$ mill -i
@ main.compile()
and observing that before this commit, the `main.compile()` call ended
up recompiling code.
|
| | |
|
| |
|
|
|
| |
- Combine `main/` and `core/`
- Rename `jsbridges/`/`scalanativebridges/` -> `worker/` for consistency with other terminology
|
| | |
|
| |
|
|
|
|
|
| |
* Simple BuildInfo plugin
* BuildInfo readme
include other known yet external plugins
* Add tests
|
| |
|
|
|
|
|
|
| |
* Add ScalaPB integration
* Update ci scripts with new scalapblib module
* Move ScalaPB integration to contrib module
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove dead code
* Upgrade zinc to 1.1.7, avoid hardcoding the version
* Fix over-compilation with Zinc
`upstreamCompileOutput` needs to contain the CompileOutput of all
recursive dependencies, otherwise Zinc gets confused when a classfile
from one of these recursive dependency is used, resulting in
over-compilation.
No tests because I don't know how to write one, but this can be observed
manually:
1. mill scalajslib.compile
2. Add an empty line to ScalaModule.scala
3. mill scalajslib.compile
Before this commit, the last compilation ended up compiling one file in
scalalib (as expected), then every file in scalajslib. After this
commit, nothing in scalajslib is recompiled, as expected.
|
| |
|
|
| |
in the background that only die when the task is re-run
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* add scala-native PR#1143 as submodule
* first pass at integrating scala-native build into mill
including worker/bridge
* add the native libraries to the compile and run classpath
* sssshhh don't be so noisy
* update scala-native to latest build WIP
* update mill to latest scala-native build-api code
* add test interface from scala-native
this code is not published ornot published at the correct scala version so copy it in for now
* implement tests for scala-native
very messy at the moment
also correct bridge version as much as possible with out a scala-native release
* update to scala-native/master
scala-native #1143 now merged
* Remove scala-native submodule
* updates for scala-native 0.3.7 release
* fixes after rebase
* make test framework agnostic and tidy dependencies
* add robust method of getting JVM classpath for running tests
support for multiple test frameworks
tidy up
* rebase fixes for 0.2.0
* add SbtNativeModule and tidy
* rebase fixes
* fix building of compile / run Classpath (via transitiveIvyDeps)
better method of loading JVM test frameworks
* add tests for build, run, utest, scalatest
* move native tests into it own trait which can be extended/overidden
* change release mode to a sealed trait instead of boolean
* add logLevel to ScalaNativeModule and plumb in
propagate release and log levels to test projects
* use test-runner from scala-native instead of including project source
add ability easily compile against scala-native snapshots
* add some docs
* update to 0.3.8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix #233 add append and exclude rules to assembly
* handle existing files and concatenation when file already exists in assembly
* add assembly tests for append rules
* tests for append patterns
* tests for exclude patterns
* make append algorithm use single map with fold over classpathIterator
* move assembly rules logic to method
* move grouping method to Assembly object, make assemblyRules Seq[_] rather than T[Seq[_]]
* add test cases for when there are no rules
* keep default parameter in createAssembly not to break CI
* add one more reference.conf entry to tests
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Use comma as separator in MILL_CLASSPATH
There is no need to use environment-specific separator, especially since
- other variables are using commas anyway, and
- it is not sent to any system-level command
* Fix whitespace
* Use MILL_CLASSPATH for Windows
* Use vm options file for client on windows
* Remove overzealous distinct
* Clean up unnecessary ceremony
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Transitive reduction of visualized graph via jgrapht now works
```
out/dev/launcher/dest/run -i visualize __.compile _
out/dev/launcher/dest/run -i visualize core.__
```
* Move test running logic from scalaworker into scalalib
This is to try and reduce the size of the classpath we are passing to the test runner subprocess, in an attempt to fix the command-line-too-long errors we're getting in Appveyor. Now the test runner subprocess should no longer need Zinc or all of it's transitive dependencies
* - Break out `GraphvizTools` into a separate Mill module, to avoid bloating the main jar and try to shorten the `MILL_SCALA_WORKER` classpath being sent to scalajslib.test (which is blowing up on windows as the CLI command is too long)
- Move the meat of `resolveDependencies` from `scalalib` to `main`, to support resolving mill modules
- DRY up resolution of mill modules in `Util.millProjectModule`
* fix mill module resolution
* Tweaks to try and make zinc work again...
* Tweak `Module#reflect` to try and make it happy with `visualize` module...
* fix integration test classpath
* move visualization into it's own module
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* initial implementation
* Upgrade to the latest version
* Add tests
* Update the code to comply with the new API
* Use reflection to call TwirlCompiler.compile function
* Run twirllib.test on CI
* Use the Java API as a workaround
* wip
* Cleanup the code (code review)
* Add an example to call the Scala API
* twirl that works with scala API
* Create functions to override the default settings (will be available in the future)
|
| | |
|
| |
|
|
|
|
| |
- Clean up root `readme.md` to remove duplication with the `docs/` folder
- Bump zinc version
|
| |
|
|
| |
We were incorrectly duplicating the JDK classpath as part of the application classpath when we spawned the Mill server from the Mill client. This makes the transmission of application classpath to the Mill server explicit via an environment variable, so we don't end up including random things from the client classloader hierarchy that we didn't expect
|
| | |
|
| |
|
|
|
|
|
|
| |
* wip
* Clean up more resources in the Mill client after every command
* catch and ignore SIGINT in Mill server to make it survive Ctrl-C on the client
|
| | |
|
| | |
|
| |
|
|
| |
build.sc
|
| |
|
|
| |
generating/using mill.vmoptions file. (#326)
|
| |
|
|
| |
Instead of count all commits back to the beginning of time twice, and
then subtracting, just make one call to let git figure it out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make builds able to depend on external projects
Builds are now able to load external projects and depend on them
as if they were local submodules.
`import $file.external.path.build`
* Disambiguate "dest" for foreign modules.
* Calling modules loaded from external directories "Foreign" to avoid
conflicting with the already existing concept of "ExternalModule".
* Amended the way `dest` is computed for foreign modules
* Added tests to check that the source paths and dest are as expected
* Added a test to show that local modules do not conflict with foreign
modules when they are named the same
* WIP windows build fail
* Added bootstrapping step in CYGWIN CI job
* * Revert externalOutPath deletion
* Add documentation for foreign-modules
* reverting appveyor changes
* Disabling Foreign modules tests against Java9
See https://github.com/lihaoyi/mill/issues/302
|
| | |
|
| |
|
|
|
| |
- Unit tests for client code using the new Java support
- Make server auto-shutdown when the client version changes, to avoid stale-server confusion
|
| |
|
|
| |
because initializing it more than once within a single process causes crashes
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
