Mill: A fast JVM build tool for Java and Scala

Post by pkolaczk » Mon, Oct 28, 2024, 4:30 PM UTC

jitl wrote: post #47

dikei wrote: post #20

Earlier quoted context omitted.

> The amount of time it takes to publish a multi-platform Kotlin library for the first time can be measured in days. I published my first Golang library in minutes, by comparison. It's a bit Apple & Orange comparison: publishing a JVM only Kotlin library is quite easy, it's the multiplatform part that takes time.

Last time I published a JVM library I had to Open A Jira Ticket to request the rights to publish a package on the main package registry. Then I had to verify I owned the DNS name prefix for my package by fiddling the DNS records at my hosting provider. It took days just to get authorized! Not including the time needed to like, figure out how to make JARs happen. In go: `git push` to a public repo In js: `npm publish`…

Post by mrudolph22 » Mon, Oct 28, 2024, 4:46 PM UTC

Post by skybrian » Mon, Oct 28, 2024, 4:50 PM UTC

mrudolph22 wrote: post #68

skybrian wrote: post #59

Earlier quoted context omitted.

I agree that Bazel did pretty well with Starlark, but the reason that’s sane is because it’s not Python, though the syntax is similar. It avoids getting into trouble with people using Python language features that would result in upgrade hell and annoy other programmers who aren’t Python experts. (Though, debugging complicated Starlark code can still be difficult.) So why not use Starlark? :)

Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.

Post by mdaniel » Mon, Oct 28, 2024, 5:02 PM UTC

beeboobaa3 wrote: post #70

carrotsalad wrote: post #66

Mill looks interesting, but, _from a Java development perspective_, it has the same fundamental challenge as Gradle (and most other build systems), which is that its config language _is something other than Java_. That means there's a significant cognitive burden to understand and manage something that one hopes to not have to think about very often. I find that the pain I experience with Gradle isn't usually about h…

My problem with gradle is that its configuration language is a programming language. Sounds amazing in practice. And it is. Until you need to fix a 3 year old build that has some insane wizardry going on.

  git clone .../ancient-codebase.git
  cd ancient-codebase
  ./gradlew  # &2
  exit 1

    $ git clone https://github.com/apache/maven-app-engine.git
    $ cd maven-app-engine
    $ mvn -B compile
    [INFO] -------------------------------------------------------------
    [ERROR] COMPILATION ERROR :
    [INFO] -------------------------------------------------------------
    [ERROR] error: Source option 6 is no longer supported. Use 8 or later.
    [ERROR] error: Target option 6 is no longer supported. Use 8 or later.
    [INFO] 2 errors
    
    $ echo "Java gonna Java"
    $ git grep -n source.*6
    pom.xml:133:            1.6
    $ sed -i.bak -e 's/1.6/1.8/g' pom.xml
    $ mvn -B compile
    [INFO] BUILD SUCCESS

Post by whartung » Mon, Oct 28, 2024, 5:03 PM UTC

rykad wrote: post #10

potamic wrote: post #4

What tends to be complex about build requirements that necessitates special purpose tools? Golang seems to be doing fine with just go build and go test. What else are people doing with gradle/maven that requires static typing, DAGs, plugins etc.?

To be blunt, nothing. The issue is that most people in jvm land are on a closed bubble and haven't seen anything else. This is true for build systems as is for non OO design for example. Most simply don't know better and the rest of us are simply stuck. Ant and then Maven started simple enough but people always find a way to justify adding more stuff. Gradle already started complex enough and they keep adding more st…