Initial Groovy setup #5747

lostiniceland · 2025-08-26T11:41:18Z

I have been working on Groovy support since I would like to use Mill for projects where tests are written in Spock/Groovy.

It is basically a modified version of the Kotlin support.

Whats currently working:

Groovy compilation (tested with 4 & 5)
Maven project layout with an additional convenience option to configure Groovy for tests only
JUnit5 test execution
Spock tests
CompileStatic
Configure Bytecode Version and Preview

If anyone would like to provide feedback I would appreciate it.

lefou

Thanks for opening this PR and welcome to Mill.

I had a quick scan and left some comments where I spotted something. Overall, this looks reasonable, but there might be some more places copied from the Kotlin implementation which aren't adequate for Groovy.

libs/groovylib/src/mill/groovylib/GroovyModule.scala

libs/groovylib/api/src/mill/groovylib/worker/api/GroovyWorker.scala

libs/groovylib/package.mill

libs/groovylib/src/mill/groovylib/GroovyModule.scala

lefou · 2025-08-26T12:58:32Z

libs/groovylib/src/mill/groovylib/GroovyModule.scala

+  override def prepareOffline(all: Flag): Command[Seq[PathRef]] = Task.Command {
+    (
+      super.prepareOffline(all)() ++
+        groovyCompilerClasspath()


Does this include potential compiler plugin dependencies?

Since there is no real Groovy compiler in the sense of Javac, Scala or Kotlin (there is Groovyc, which is just a CLI wrapper) I guess there is no need for this. The core Groovy dependency is able to compile and you can just extends the normal classpath. Guess this is due to Groovy being a dynamic language where everything is resolved at runtime anyways. The only difference could be when you use @CompileStatic (doc). I will add this to the tasks to be evaluated.

libs/groovylib/src/mill/groovylib/GroovyModule.scala

libs/groovylib/src/mill/groovylib/TestGroovyMavenModule.scala

libs/groovylib/src/mill/groovylib/GroovyModule.scala

lefou

I understand, that you copied another language module to start this implementation, but it would be helpful, if you could revise it and delete all tasks that aren't needed, like groovycOptions.

lostiniceland · 2025-09-15T14:12:11Z

@lefou I've resolved most of the issues and fixed the Spock bug.

I've also extended the use-cases and backed them by tests to support static compilation as well as a 3-stage compilation for setups where Java depends on Groovy and vice-versa.

In the next weeks I will probably find some more time to see about what configuration options are needed and how to support them.

lefou · 2025-09-16T06:27:34Z

@lostiniceland Can you resolve the merge conflicts?

lostiniceland · 2025-09-16T07:39:39Z

@lefou I would like to pull bomMvnDeps up to JavaModuleBase in order to setup BOMs within the TestModule.Spock utility (I guess other testframeworks provide BOMs as well).
Would this break compatibility? If not, are there other reasons why it is not there?

lefou · 2025-09-16T07:51:55Z

@lefou I would like to pull bomMvnDeps up to JavaModuleBase in order to setup BOMs within the TestModule.Spock utility (I guess other testframeworks provide BOMs as well). Would this break compatibility? If not, are there other reasons why it is not there?

You can try, but I think it will break bin-compat.

lostiniceland · 2025-09-16T08:28:18Z

@lefou I would like to pull bomMvnDeps up to JavaModuleBase in order to setup BOMs within the TestModule.Spock utility (I guess other testframeworks provide BOMs as well). Would this break compatibility? If not, are there other reasons why it is not there?

You can try, but I think it will break bin-compat.

I gave it a try and no additional test broke. From SemVer perspective it also shouldn't break anything as long as the trait provides a default implementation. So I will keep this for now.

lostiniceland · 2025-09-16T13:27:14Z

@lefou Have a look at the latest commit

I managed to manage (pun intended) the JUnit5/Spock dependencies. Since the BOMs are only available at certain versions this will be checked.
For JUnit starting from 5.12 this has the nice effect that the junit-bom manages the platform-launcher version. So there is actually no need to specify this (but removing the property will break compatibility).
So I've implemented it according to these rules:

platform-launcher version set => add launcher with specific version
no launcher version, but junit-bom available => add launcher without version (because managed)
else => don't add launcher
This should make the usage easier.

What do you think? Do you want to keep this, or should I remove it?

…pile which also fixed spock not being executed

Starting with JUnit 5.12 and Spock 2.3 a BOM is available on Maven Central. If the version matches the BOMs will be automatically added. For JUnit, this has the effect that the platform-launcher is also managed in the BOM so it is actually not necessary to specify a platform-launcher-version. Hence the launcher is also added when the version is not set and the minimum version is met.

lostiniceland · 2025-09-23T14:10:49Z

Looks like I was wrong about binary compatibility though I am not quite sure what to make of this:
https://github.com/lostiniceland/mill/actions/runs/17948459255/job/51041447311

Lets say Groovylib is released with Mill 1.0.10 then I cannot use this with Mill 1.0.9. Fine. And plugins targeting 1.0.10 will also still be compatible since the new method has a default implementation.
Currently I don't really trust this test.

…t transoformations

lostiniceland · 2025-09-24T12:52:41Z

@lefou I think this PR is ready to get out of the draft status.

I've added examples and docs (though ./mill docs.fastPages didn't do anything), added most relevant compiler options, and I've been using it for Spock testing in a side project for some weeks now without problems.

There is this outstanding issue with the binary-compatibility caused by adding bomMvnDeps to the TestModule base (see previous message) which I think should actually work. Maybe @lihaoyi can provide insight. If this really breaks compat, then I will have to remove the feature that a BOM is automatically added for certain Test setups.

lihaoyi · 2025-09-24T17:02:50Z

I haven't reviewed this in detail, but let's put this in contrib/ rather than libs/. That will send the right signal that it is new and experimental, and if it becomes popular we can move it into libs/ with the Java/Scala/Kotlin toolchains

lostiniceland · 2025-09-25T08:11:56Z

I haven't reviewed this in detail, but let's put this in contrib/ rather than libs/. That will send the right signal that it is new and experimental, and if it becomes popular we can move it into libs/ with the Java/Scala/Kotlin toolchains

Do I have to change the package from mill.groovylib to mill.contrib.groovylib? It would be the correct way, but it just creates more work and I am quite confident that the module is in a good shape. I'd rather spent my time on adding tests for the recently added compiler options (currently only tested manually)

lefou · 2025-09-26T07:03:56Z

Since we also have experimental pythonolib and javascriptlib not in contrib, I think it's ok to have a groovylib, as long as it is marked as experimental.

We already have the example tooling in place for <lang>lib modules, which is quite different to contrib modules.

lihaoyi · 2025-09-26T10:43:09Z

Since we also have experimental pythonolib and javascriptlib not in contrib, I think it's ok to have a groovylib, as long as it is marked as experimental.

We already have the example tooling in place for <lang>lib modules, which is quite different to contrib modules.

Sounds good to me!

lefou · 2025-09-16T13:46:05Z

libs/groovylib/api/src/mill/groovylib/worker/api/GroovyWorker.scala

+  /**
+   * In a mixed setup this will compile the Groovy sources to Java stubs.
+   */
+  def compileGroovyStubs(
+      sourceFiles: Seq[os.Path],
+      classpath: Seq[os.Path],
+      outputDir: os.Path
+  )(implicit
+      ctx: TaskCtx
+  )
+      : Result[CompilationResult]


What is the output of this? .class files or .java files?

.java though they are cleaned up after the last groovy compilation stage.

I think using CompilationResult in the return isn't appropriate here.

Is this stub-handling somewhere documented? Or can you outline the process and what you mean with "cleaned up after the last compilation stage"?

It looks to me, this groovy stubs should reside in it's own cacheable task, since it should not need to be regenerated when just Java files changed.

I will document it.

In order for Java to compile with dependencies to Groovy, It only needs the method signatures (headers). This is what the Groovy Stubs are. When you have dependencies Groovy -> Java AND Java -> Groovy you need a 3 stage compile

Groovy compiles to Java stubs (*.java files in the output)

Java compiles with the Stubs available
2.1 Cleanup stubs after Java compile (I was wrong before, it happens here)

Compile Groovy (now all Java dependencies are also available on the compilepath).

It should actually be very similar in the other toolchains (scala, kotlin) but maybe the external compiler handles this already internally.

There is a difference to Scala or Kotlin handling. Both are able to read Java files, so they will always compile their files first and the Java-compiler comes last. Whereas Groovy will first generate stubs, so Java can consume them and succeed with compilation, and then compile Groovy (while consuming the compiled Java classes vie the classpath).

Nevertheless, the only thing needed is a changed classpaths and output paths. There is no need to delete stub files. Especially, since they are needed in the next compile run and don't need any regeneration at all, when nothing has changed to the Groovy files. And even if the Groovy files have changed but the resulting stubs have not, there is no need no recompile Java files at all. Both cases would be automatically handled by Mill, if we properly model it via cached tasks.

lefou · 2025-09-26T07:52:36Z

libs/groovylib/src/mill/groovylib/GroovyModule.scala

+  private def isGroovyBomAvailable: T[Boolean] = Task {
+    if (groovyVersion().isBlank) {
+      false
+    } else {
+      Version.isAtLeast(groovyVersion(), "4.0.26")(using Version.IgnoreQualifierOrdering)
+    }
+  }


The name is misleading. It should be useGroovyBom or groovyUseBom, since it's not checking for availability but deciding (based on the version).

lefou · 2025-09-26T07:56:57Z

libs/groovylib/src/mill/groovylib/GroovyModule.scala

+   *   def targetBytecode = Some("17")
+   * }}}
+   */
+  def targetBytecode: T[Option[String]] = None


Should be groovyCompileTargetBytecode

lefou · 2025-09-26T15:06:39Z

libs/groovylib/src/mill/groovylib/JavaMavenModuleWithGroovyTests.scala

+/**
+ * Convenience trait for projects using Java for production and Groovy for tests in a Maven setup
+ */


You should add more motivation, why this might be preferable over just adding GroovyModule (e.g. to avoid implicit groovy deps in the module).

lostiniceland force-pushed the groovylib branch from fe154eb to a7455f8 Compare August 26, 2025 12:53

lefou reviewed Aug 26, 2025

View reviewed changes

lihaoyi changed the title ~~Intial Groovy setup~~ Initial Groovy setup Aug 27, 2025

lefou reviewed Aug 28, 2025

View reviewed changes

libs/groovylib/src/mill/groovylib/GroovyModule.scala Outdated Show resolved Hide resolved

lefou reviewed Aug 28, 2025

View reviewed changes

libs/groovylib/src/mill/groovylib/GroovyModule.scala Outdated Show resolved Hide resolved

lefou reviewed Aug 28, 2025

View reviewed changes

libs/groovylib/src/mill/groovylib/GroovyModule.scala Outdated Show resolved Hide resolved

lefou reviewed Aug 28, 2025

View reviewed changes

lostiniceland force-pushed the groovylib branch 2 times, most recently from 21334e0 to 69cb09a Compare September 15, 2025 14:08

lostiniceland force-pushed the groovylib branch from 69cb09a to f7cd2cf Compare September 16, 2025 07:36

lostiniceland force-pushed the groovylib branch from bfbe1fe to c82f9a2 Compare September 16, 2025 13:21

lostiniceland added 6 commits September 23, 2025 11:24

Intial Groovy setup

a668cb2

adding more test cases and fixing classloader issue during groovy com…

c795348

…pile which also fixed spock not being executed

improve test-only-groovy to not rely on an existing outer module

91c58ff

3-stage compile to support Groovy <-> Java cycles

8a196f9

test with cross-compile Groovy 4 & 5

022b8f4

lostiniceland force-pushed the groovylib branch 2 times, most recently from 32f8111 to bda67ee Compare September 23, 2025 13:44

lostiniceland added 2 commits September 24, 2025 11:27

samples

3ccf9f2

docs

39cdc7e

lostiniceland force-pushed the groovylib branch from 9bb4038 to 39cdc7e Compare September 24, 2025 10:15

[autofix.ci] apply automated fixes

339e1bf

Groovy Compiler options for bytecode version, preview features and as…

52c32b5

…t transoformations

[autofix.ci] apply automated fixes

2e541d0

lefou added 2 commits September 26, 2025 10:41

Merge branch 'main' into groovylib

0d2918a

Added example tests to CI setup

1ecad63

lefou marked this pull request as ready for review September 26, 2025 10:49

lefou and others added 4 commits September 26, 2025 14:29

Rudimentarily fix webpage generation

55a5d77

Cleanup and Testcase for targetBytecode and previewEnabled

30204b7

[autofix.ci] apply automated fixes

50db51e

minor test improvement

b756104

lefou reviewed Sep 26, 2025

View reviewed changes

lefou added 2 commits September 27, 2025 10:03

Mark API as experimental

e4a3e5d

Fix mima setup

34cb54e

Uh oh!

Initial Groovy setup #5747

Are you sure you want to change the base?

Initial Groovy setup #5747

Uh oh!

Conversation

lostiniceland commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lefou left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lefou left a comment

Choose a reason for hiding this comment

Uh oh!

lostiniceland commented Sep 15, 2025

Uh oh!

lefou commented Sep 16, 2025

Uh oh!

lostiniceland commented Sep 16, 2025

Uh oh!

lefou commented Sep 16, 2025

Uh oh!

lostiniceland commented Sep 16, 2025

Uh oh!

lostiniceland commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lostiniceland commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lostiniceland commented Sep 24, 2025

Uh oh!

lihaoyi commented Sep 24, 2025

Uh oh!

lostiniceland commented Sep 25, 2025

Uh oh!

lefou commented Sep 26, 2025

Uh oh!

lihaoyi commented Sep 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lefou Sep 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lostiniceland Sep 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lefou Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

lostiniceland commented Aug 26, 2025 •

edited

Loading

lostiniceland commented Sep 16, 2025 •

edited

Loading

lostiniceland commented Sep 23, 2025 •

edited

Loading

lefou Sep 27, 2025 •

edited

Loading

lostiniceland Sep 27, 2025 •

edited

Loading

lefou Sep 28, 2025 •

edited

Loading