What's necessary to make Mill good for building Java ecosystem projects?

[lihaoyi]

One of my mid-term goals is to try and make Mill an attractive environment for building Java projects. Most Java projects are on Maven or Gradle (IntelliJ Developer Survey), so people are already writing Groovy or XML to configure their builds, and getting them to learn Scala doesn't seem like such a stretch (despite Scala's reputation for confusingness)

Scala and Java are close enough that a bunch of the stuff already translates over: dependencies, classpaths, jars, assemblies, etc..
We already have decent support for Java as a language, including a dedicated section in the documentation (https://mill-build.org/mill/0.11.11/Java_Intro_to_Mill.html). If we like Mill and think it's intuitive, then it would be great if other JVM language folks could benefit from using Mill to build their projects

But Java as an ecosystem does things differently than projects using Scala, and so there is probably more work to be done to make using Mill an attractive option. The question is, what?

Some ideas off the top of my head:

1. First class support for big Java frameworks:

   • Testing frameworks (JUnit, Mockito, Powermock, TestNG)
   • Web frameworks (Spring Boot, Spring MVC, Quarkus, Micronaut)
   • Linters (Checkstyle, Errorprone, Findbugs)
   • Autoformatters (Google Java Format, Spotless)
   • Code Coverage (Jacoco)

2. Support BOMs and dependency management (Support BOMs/dependencyManagement coursier/coursier#1390)

3. Work to get rid of weird DSLs and Scala-isms (Make T an alias for Task instead of Target, move T.* operations to Task.* #3356)

4. Support Kotlin? https://github.com/lefou/mill-kotlin already exists, but we could in-source it and provide the same fleshed out documentation we now provide for Java and Scala

5. Port SBT-Pom-Reader to Mill, to simplify the migration story https://github.com/sbt/sbt-pom-reader

6. General quality-of-life improvements: better IDE support, better CLI, better performance, etc.. Not necessarily specific to Java, but would benefit anyone using Mill

What else do we need to make Java folks feel at home using Mill? Please let me know what you think below!

[Krever]

I’m not sure how popular that is, but at some point when using Java ecosystem, I was almost forced to use "annotation processors". It was the first and only time I've seen this, and quick research indicated that there is no easy way to use this in sbt. If it's a popular mechanism in java, it might be something to add to mill. It would also benefit scala builds.

https://picocli.info/#_annotation_processor

[lefou]

We have an example for using an annotation processor in the documentation:

• Annotation Processors with Lombok

[Krever]

Ah, didn't know, thanks and sorry for noise.

[lefou]

Ah, didn't know, thanks and sorry for noise.

It's not noise. Any feedback helps. Thank you!

[nafg]

I'm curious what is the impetus behind trying to target Java devs?

[roman-mibex-2]

• A bigger audience
• There are certainly tons of non-standard (aka don't fit well into Maven defaults) suffering from clunky builds.

[nafg]

My question wasn't why might Java developers want Mill, it was why does Mill want Java developers

[lihaoyi]

For the same reason we want Scala developers: because its cool, and we would like to share its coolness to benefit as many people as possible

[lefou]

I wonder whether there are any Eclispe IDE users? If not for Scala or Kotlin, Eclipse IDE used to be a nice performer, so the question is, whether we might want to add a generator for some rudimentary Eclipse IDE project files (.classpath and .project and some files under .settings/).

[lefou]

Maybe, if we write a nice tutorial how to publish to Maven Central, from account creation at Sonatype, over generating a token up to setting it up in Mill and maybe automation via GitHub, we may cover a very pressing topic.

These questions were asked in all JVM communities and having a single link to up-to-date documentation could be a game changer. It's not easy in any build tool, but besides the typical network issues and unavailability of Sonatype services (which we should mention with example how to identify) it works rather nice in Mill. The workflows are much better that e.g. in Maven, where you can find whole plugins just to manage editing pom.xml files and git-commits to get a release out.

[yawaramin]

Yes. What this discussion shows is that Mill is trying to do DevRel and reach a wider audience. Something I heard recently is that the essence of DevRel is that you ask what problems developers have (eg 'I need to figure out how to publish to Sonatype') and try to solve them.

So the key is to ask what problems Java developers have (that can be solved by Mill).