-
-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix testing as Java application #3432
Conversation
@AnthonyGrod can you revert all non-essential formatting changes in the PR so it is easier to review exactly what you are trying to do |
@lihaoyi sorry, done. |
Thanks @AnthonyGrod ! |
I think this looks reasonable, would be good if @lefou could take a look before I merge it |
@AnthonyGrod can you update the PR description to include how you tested this? Manual testing is fine, but we should at least write down how it was done in case someone needs to reproduce the test in future. After that I can merge this |
@lihaoyi I have updated the description. |
Thanks! |
Hello, I'm currently working on integrating Mill over the BSP plugin for IntelliJ (https://github.com/JetBrains/hirschgarten - now the BSP plugin code is merged with Bazel-related plugins).
I have stumbled upon an issue, where the
Test <module.name> as Java application
action did not work with a testing suite. It only performed a Query JVM environment task and tests were not run (later on it turned out that it was caused by thezincWorker
inMillJvmBuildServer#jvmRunTestEnvironment
, which could not find the correct test main class).After digging into firstly the BSP plugin's code and later on Mill's code, I discovered that in the
MillJvmBuildServer#jvmRunTestEnvironment
there is testing logic lacking. It did not manage to fetch the correct test-specific main class, classpath and main arguments necessary for the testing as a local Java application.I figured out that in order to make it work, I needed to leverage the
TestModule
's logic - I reproduced theMillJvmBuildServer#testTask
logic of creating the java process' arguments and used it in a newTestModule#getTestEnvironmentVars
function, which is then used in theMillJvmBuildServer#jvmRunTestEnvironment
in case of aTestModule with JavaModule
module (note: the code reproduction I've done might not be the most graceful solution - please let me know if I can do it better). Then the test-specific main class, classpath and main arguments I mentioned are assigned to adequate fields of the function's result -JvmEnvironmentItem
, which is finally used on the BSP plugin side, which launches the actual local Java application.I tested the solution with an example Mill project (generated with the g8 template). With BSP plugin installed, I imported the project with the new importing via BSP plugin option (it's still WIP and not yet available in official Scala plugin distribution). Then I checked that indeed the
Test <module.name> as Java application
gutter triggers the tests and their result is displayed in the terminal.If you need any help with e.g. setting up the BSP plugin, I'm happy to help