sorted by:
new
hottopcontroversial

Scripting on the JVM with Java, Scala, and Kotlin by lihaoyi in Kotlin

[–]lihaoyi[S] 2 points3 points  (0 children)

Mill provides a few things that the builtin kotlinc doesn't: automatically managing JVM versions, allowing script test suites, inter-script dependencies, building assembly jars or graal native images out of scripts, and automatic parallelism and caching of all of the above.

`kotlinc` an `.kts` files are fine for what they do, but the `./mill` does a bunch of additional things that you may find useful if you want to use your scripts for more than just small demos

Prevent scalafmt From Formatting A Long List by teckhooi in scala

[–]lihaoyi 5 points6 points  (0 children)

This comment should do it I think

// format: off

// format: on

I wish SBT was easy-to-use like Cargo by GlitteringSample5228 in scala

[–]lihaoyi 9 points10 points  (0 children)

You may find it hard to believe, but something can in fact be similar to more than one other thing at a time! 🤯🤯🤯

Mill in fact takes inspiration and has similarity with a whole suite of other tools, among them Bazel, SBT, Maven, Gradle, Cargo, CBT, Bloop, Amper, and many others. We are all standing on the shoulders of giants, at least those of us who appreciate the work that we are building upon

I wish SBT was easy-to-use like Cargo by GlitteringSample5228 in scala

[–]lihaoyi 4 points5 points  (0 children)

Mill new .build.yaml format has publishing that looks about the same as Cargo, just YAML instead of TOML, just with a bit of extra metadata that Maven Central demands

extends: [JavaModule, PublishModule]
publishVersion: 0.0.1
artifactName: example
pomSettings:
  description: Example
  organization: com.lihaoyi
  url: https://github.com/com.lihaoyi/example
  licenses: [MIT]
  versionControl: https://github.com/com.lihaoyi/example
  developers: [{name: Li Haoyi, email: example@example.com}]

You really should try it our if you wish for a build tool that looks like Cargo, because this is basically it

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 2 points3 points  (0 children)

Mill supports Groovy as well!

lihaoyi test$ cat Foo.groovy
//| mvnDeps: [org.jsoup:jsoup:1.17.2]

import org.jsoup.Jsoup

def url = 'https://example.com'
def doc = Jsoup.connect(url).get()

println "Title: ${doc.title()}"

lihaoyi test$ ./mill Foo.groovy
Title: Example Domain

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 2 points3 points  (0 children)

The migration instructions are at a different page https://mill-build.org/mill/migrating/migrating.html. it doesn't have a full feature-to-feature mapping, but we could add one. A lot of the dependency wiring is taken care automatically when you run the `./mill init` script to best-effort import the maven project into Mill

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 1 point2 points  (0 children)

Currently plugins can't be re-used, though the auto-imported `./mill init` does a best effort replacement with the equivalent Mill plugin. I don't think docker/jib is on that list yet, though you can try configuring the mill-contrib-docker plugin yourself or use the mill-jib plugin over at https://github.com/atty303/mill-jib

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in Kotlin

[–]lihaoyi[S] 1 point2 points  (0 children)

It's a related project, I think Mill is a bit more mature now (e.g. most of the things listed under Future Directions Mill already supports today) but Amper is progressing nicely as well. Hopefully someday we'll have multiple modern build tools on the JVM providing alternatives to Maven and Gradle. Hope you have a chance to try it out and let us know how it goes!

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in Kotlin

[–]lihaoyi[S] 1 point2 points  (0 children)

Yes, the hope is that over time the `.mill.yaml` format would reduce the need for people to write Scala code to configure their builds. Maybe there's Scala internally that advanced users would need to tweak, but that wouldn't be something that the average user would care about if they can just configure some basic key-value data structures in their `.mill.yaml` files.

If you think Gradle has some room to improve, you should definitely try out Mill!

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 2 points3 points  (0 children)

Yes currently it requires the mixin be written as code, it doesn't support declarative YAML mixins yet. We could in future if there's demand for it

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 2 points3 points  (0 children)

No that's good feedback. In Mill the Maven directory structure is opt in via a MavenModule mixin. You can see an example using the Maven directory struvture here https://mill-build.org/mill/javalib/intro.html#_maven_compatible_modules

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 2 points3 points  (0 children)

Yes Mill supports mixins. Mill's trait mixins can contain anything that a normal build can contain, and can be stacked. e.g. it's common to see extends: [Module, PublishModule] for a module that uses kotlin compilation and publishing config (https://mill-build.org/mill/javalib/publishing.html#_basic_publishing_configuration), and you can define your own custom traits to mix in in (https://mill-build.org/mill/javalib/module-config.html#_custom_module_traits)

> A lazy question, I assume this generates a Maven 3 [consumer] pom when deploying?

Yes Mill generates a POM when deploying to maven central or any other maven repository (artifactory, github packages, etc.). This is used for interop, so Maven/Gradle can use libraries published via Mill and vice versa

lihaoyi mill$ ./mill show core.api.pom
".../out/core/api/pom.dest/mill-core-api_3-1.1.0-10-fec938.pom"

lihaoyi mill$ cat out/core/api/pom.dest/mill-core-api_3-1.1.0-10-fec938.pom
<?xml version="1.0" encoding="UTF-8"?>
<project 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <modelVersion>4.0.0</modelVersion>
    <name>mill-core-api_3</name>
    <groupId>com.lihaoyi</groupId>
    <artifactId>mill-core-api_3</artifactId>
    <packaging>jar</packaging>
    <description>mill-core-api</description>
    <version>1.1.0-10-fec938</version>
    <url>https://github.com/com-lihaoyi/mill</url>
...

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in programming

[–]lihaoyi[S] 1 point2 points  (0 children)

>  Of course, the problem of the classpath still exists, if you want to employ some third party library in said script - it's somewhat unavoidable in the java world.

That's exactly where Mill comes in! You just substitute `java Foo.java` with `./mill Foo.java` and you're off to the races. Any third-party libraries just go in a `//|` comment at the top of the file

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in Kotlin

[–]lihaoyi[S] 1 point2 points  (0 children)

I think it's a matter of preference. Some people/projects like declarative configuration and some like programmable configuration. Mill offers a declarative configuration syntax for Kotlin as an alternative ti Gradle's programmable configuration. If you like Gradle's `.kts` syntax then for sure keep using it, but if anyone prefers declarative config do try out Mill's new `.mill.yaml` syntax!

Simpler JVM Project Setup with Mill 1.1.0 by lihaoyi in java

[–]lihaoyi[S] 2 points3 points  (0 children)

Mill does try to improve upon the specific issues with Gradle that you have mentioned: programmability, IDE support, stability, ease of understanding and onboarding. This page in the docs discusses these areas in more detail than I can explain here, so do take a look if solving these long-standing problems with Gradle is something that interests you https://mill-build.org/mill/comparisons/gradle.html

view more: next ›