Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mill: A fast JVM build tool for Java and Scala

mill-build.org

Post reply on HN
Print view View original

161–168 of 168 posts

Re: Mill: A fast JVM build tool for Java and Scala

#161

Post by zcw100 »

mrudolph22 wrote: post #73

I gave Mill a try earlier this year. My hope was to escape the nightmare that is Gradle, which I've been using for many years. Mill sounds great in theory (except for the Scala DSL). Unfortunately, I couldn't get a basic Java build to work in half a day, even though I have (admittedly rusty) working knowledge of Scala. It was one obscure error after another. My conclusion was that Java support isn't ready. There was…

I've had the same gripe about having to keep up with a second language just for the build tool for a while. Try taking a look at JeKa https://jeka.dev/

Re: Mill: A fast JVM build tool for Java and Scala

#162

Post by dkarl »

cyberax wrote: post #115
dkarl wrote: post #114

Earlier quoted context omitted.

When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.

> When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.

Then you don't have a standard build, you have a build with multiple steps that needs to be documented and/or scripted. In an organization where every other project builds in a single step with "mvn package", and people can check out a repo and fire up their IDE and stuff just works, people are going to get bent out of shape because from their perspective, things aren't working out of the box.

A slightly more powerful build tool that supports custom code in the build doesn't force users to script around it. You can create an arbitrarily customized build that builds with the same commands as a Hello World project. (It's a double-edged sword, to be sure, because people don't try as hard to avoid customization as they would with Maven.)

Re: Mill: A fast JVM build tool for Java and Scala

#163

Post by rileymichael »

pkolaczk wrote: post #151
rileymichael wrote: post #147

Earlier quoted context omitted.

How does that differ from `gradle init`?

Init and then what? The story of discovering and adding dependencies is still much worse. Nothing like cargo add/remove or crates.io where I can quickly search dependencies with their descriptions with standardized links to repos and documentation. Actually even Python is nicer in this regard with PyPi and pip install, even though virtual envs are pain.

https://central.sonatype.com/ and https://mvnrepository.com/ are exactly that

Re: Mill: A fast JVM build tool for Java and Scala

#164

Post by hocuspocus »

jitl wrote: post #160
kelnos wrote: post #146

Earlier quoted context omitted.

Not the author, but this is unfortunately a bit more difficult than it sounds. Like for example, where do you get the name of the jar file to build? I guess you could use the name of the root directory, but that may not be ideal. How do you figure out dependencies? Import statements in .java files give you the packages to import, but those package names could be provided by one or more .jar files and, regardless, the…

Name of the jar? `java build jar/foo` -> foo.jar, `java build src/dog` -> dog.jar. Dependencies? It's okay to use a dependency list file for these - I guess I don't consider this config compared to the stuff I usually find in a Gradle or Maven file. The thing I'm alergic to is all the stuff that isn't a dependency list. In Go, these go in a go.module file that's automatically updated by the build tooling, which runs…

There are initiatives like declarative Gradle or JetBrains' Amper. But I assume they'll hit a wall in real-life exactly like Maven does. Think about packaging for instance, I see at least 4 or 5 different ways that are fairly common, and that's for one target only.

Re: Mill: A fast JVM build tool for Java and Scala

#165

Post by beeboobaa3 »

dkarl wrote: post #114
cyberax wrote: post #102

Earlier quoted context omitted.

> it can't be local to the project It certainly can be, in the same repository.

When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.

I'm using several maven plugins (not extensions) that are defined within the reactor project itself. It works well.

You do need to split your build into multiple projects governed by a reactor but you'll have that anyway as soon as you have more than 1 module. Then you just always build the reactor. Pretty much the same idea as gradle.

Re: Mill: A fast JVM build tool for Java and Scala

#166

Post by beeboobaa3 »

lihaoyi wrote: post #135
cyberax wrote: post #115

Earlier quoted context omitted.

> When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.

You can, but why should you need to? Why can't the build tool take the plugin code directly off of disk, build it, and use it? This kind of orchestration of manual steps is what build tools are meant to be good at

It can, for plugins. GP is talking about extensions which you typically don't need.

Re: Mill: A fast JVM build tool for Java and Scala

#167

Post by jfyasdfuwas »

kaba0 wrote: post #82
pkolaczk wrote: post #62

Earlier quoted context omitted.

> It’s extremely rare that everything fits nicely into “cargo build” 161538 crates do not agree with you ;)

Which are mostly small, isolated library code , whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools. What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?

The apps are also built using cargo build.

For your outlandish use cases you can use Bazel.

Post reply on HN