Beginning of Bloop integration #595
Conversation
|
Pinging @jvican for obvious reasons |
There was a problem hiding this comment.
Do you mind to add some (minimal) documentation about the plugin to docs/pages/9 - Contrib Modules.md? At the current state the most interesting info a user seeks might be the status (what works, what not) and the relation to the mill plugin in the bloop repo (which one is newer).
|
@lefou sure, will do 👍. Could you also provide guidelines regarding testing ? What tests would you expect to see in this PR ? Should I follow the GenIdea tests ? |
|
For testing, we need to cover the file generator (which is like the |
|
If you need further help with initial test setup, have a look at other contrib project or ask on gitter. |
Gotcha. In the interest of keeping PRs small(ish), I'll remove the compilation task and will add it to a subsequent PR with the relevant tests. Thanks for the pointers. |
This facilitates testing by preventing the trait from referencing a global module.
| @@ -12,12 +12,12 @@ object TestEvaluator{ | |||
| val externalOutPath = os.pwd / 'target / 'external | |||
|
|
|||
|
|
|||
| def static(module: TestUtil.BaseModule)(implicit fullName: sourcecode.FullName) = { | |||
| def static(module: => TestUtil.BaseModule)(implicit fullName: sourcecode.FullName) = { | |||
There was a problem hiding this comment.
This is needed to accommodate a cyclic reference (BloopImpl requires an evaluator contains a path-dependant trait ) (see https://github.com/lihaoyi/mill/pull/595/files#diff-e6a90b093d6e78436bdcedf02eab38dcR23)
|
@lefou, I'm happy for this PR to be reviewed |
| * Resolves artifacts using coursier and creates the corresponding | ||
| * bloop config. | ||
| */ | ||
| def artifacts(repos: Seq[coursier.Repository], |
There was a problem hiding this comment.
Calling coursier directly as the logic needs to retain the dep => path relation
| ////////////////////////////////////////////////////////////////////////////// | ||
|
|
||
| // Version of the semanticDB plugin. | ||
| def semanticDBVersion: String = "4.1.0" |
| ```scala | ||
| // build.sc (or any other .sc file it depends on, including predef) | ||
| // Don't forget to replace VERSION | ||
| import $ivy.`com.lihaoyi::mill-contrib-bloop:VERSION` |
There was a problem hiding this comment.
Is it possible to programmatically run this setup? For example mill --extra-predef /tmp/metals.sc mill.contrib.Bloop/install. It would be nice if we could support mill in the "import build" command in Metals, the same way it works for sbt.
There was a problem hiding this comment.
Just had a go at it : mill --predef /tmp/metals.sc mill.contrib.Bloop/install would work
There was a problem hiding this comment.
Cool, we're working on adding automatic "import build" for Gradle in Metals, which requires abstracting some sbt-specifics away. I'm optimistic it won't be too much effort to add automatic "import build" for Mill after that.
|
@Baccata Similar to the summary on Metals support, it would be great if the documentation also summarizes IntelliJ integration (as an alternative to mill's GenIdea) with regards to importing mill project into IntelliJ, compilation on change via Bloop, running/debugging apps/tests, etc., and perhaps refer to the documentation on IntelliJ's support for BSP/Bloop for more information. |
In all frankness, I'm not planning on testing any of that myself... at least not before the Intellij-Bloop integration gets out of EAP and reaches mainstream releases. I'd rather someone who's actively interested in those things try them out and see if they work, and amend the documentation after doing so. |
|
Hmm... I'm currently using IntelliJ 2019.1.1 with IntelliJ Scala 2019.1.7, and I can see that it has BSP and Bloop in the build tool configuration. I think those are mainstream releases; anyway, just a suggestion. |
|
Great, I'm going to merge. @Baccata What do you think about your commit history? Does keeping all commits make sense, or should I squash? |
|
I won't be offended if you squash them, most of the commits are clean but I did mess a couple of them |
This is the first of a series of PRs that aims at giving mill modules the ability to delegate some tasks to bloop. I have some more complex stuff lined up, but thought it'd be easier to split the work into smaller PRs.
I initially had started the integration against the bloop repository, but mill's API evolving faster makes it hard to ensure that the integration remains up to date, and I believe this as its place here (happy to have the debate)
This first PR does the following:
BloopModuletrait that can be mixed in a mill's JavaModule, giving the ability to callmill module.bloop.configand. (edit : compiling with bloop will occur in a subsequent PR)mill module.bloop.compileThe aim of this first PR is to lay the basis for the integration. It does not address scalajs/scalanative specific usecases. In subsequent PRs, I'm planning to use a mill worker to maintain a bsp connection between mill and bloop to allow the implementation of more complex tasks (testing in particular, the results of which cannot be easily retrieved via mere shellout).
The
BloopModuletrait does not extendScalaModule(norJavaModule). This is to build on the existing modules and let the users decide whether the want to override theircompiletasks by callingbloop.compile, or whether they want to retain the freedom to call either tasks.I haven't added unit-tests yet, and would appreciate some guidance around testing : should I just follow what's been done around the GenIdea module ?Unit tests added