It's not clear to me what is the problem you have with Gruber or this post. He's just a journalist/blogger who's covered Apple and related topics by, you know, publishing his own writing on his own website (for over 20 years). You seem angry that such a person exists, or that someone can be enthusiastic about some things having to do with Apple while criticizing others. I really don't understand the animosity towards him and his site that seems to be simmering away in this community.
In what way is he being a "political fanatic" in this post? His writing has never been politically neutral - nor has he ever claimed it was - but this post calling out the lameness of a bunch of tech CEOs posting similar ass-covering congratulations to the winner of the presidential election - especially the ones who clearly would have preferred a different winner - could have been written by anyone.
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 how to do something clever or customized etc, but instead it's when I haven't thought about Gradle syntax in the last 3 months since everything has been silently working, but now I need to figure out some small thing, and that means I need to go re-learn basic Gradle stuff - whether it's groovy, Kotlin, or some aspect of the build DSL - since my mind has unloaded everything about Gradle in the meantime.
Simplifying the semantic complexity of a general purpose build system will always help, but the most useful thing for me would be if the configuration for a Java build were to natively use the Java language directly.
It's intended as a replacement for _scala_ builds. Having a build definition in the native language that doesn't require a different syntax (like a declarative syntax such as maven xml or toml) makes task customization easier for the maintainer of a given project. Unfortunately, it also means that you have to know the language and read the documentation for the build system.
If you want something declarative, there's also bleep[1] in the scala ecosystem. And for single module builds there's scala-cli[2]. It's also possible to use gradle and maven for scala projects, but for an java-only shop I wouldn't be using mill or bleep because there's no need to introduce a new language just to manage the build. For scala/java/kotlin hybrid projects though, gradle or mill or sbt would be my recommended tool because of how tightly they are coupled with the cross-platform build matrix nature of scala library and build system plugin ecosystems. For larger builds, it's mill or bazel because there s a performance cliff in sbt and gradle, and bleep is too new to have all the standard plugins ported. We use mill at writer.
The intention has changed, Mill now explicity targets Java and Kotlin as well. It now has dedicated Java/Kotlin docsite
sections and examples, and has grown integrations with Palantir-Format, Checkstyle, Errorprone, Jacoco, and all their Kotlin equivalents (ktfmt, ktlint, kover).
Java and Scala (and Kotlin) are remarkably similar from a tooling perspective, so Mill tries to target both using the same shared infrastructure
> It's intended as a replacement for _scala_ builds. Having a build definition in the native language [...] makes task customization easier for the maintainer
Totally agree! But the title of the post says "Mill: A fast JVM build tool for Java and Scala" :) - it certainly looks like better tool for the Scala community.
For projects that are primarily building Java sources, it'd be nice to have a build system that uses Java code to describe the build. I don't think this exists at the moment.
Even in Java, because the language is relatively verbose, many frameworks fall back to an "inner platform" of magic annotations which have the same problem: e.g. just because you know how Java works doesnt mean your mind hasn't unloaded all the SpringBoot annotation semantics! But despite that it is worth it, because conciseness does matter.
Mill using Scala syntax is like that, but with the added advantage that even if you forget how Scala works, your IDE does not. You can really lean on Intellij or VScode to help you understand and navigate around a Mill build in a way that is beyond what is possible for most build tools: You can autocomplete things, peek at docs, navigate the build graph and module tree, etc. and learn what you need to learn without needing to reach for Google/ChatGPT. I use this ability heavily, and I hope others will enjoy these benefits as well
> Until you need to fix a 3 year old build that has some insane wizardry going on.
My experience with Gradle is that it's the "3 year old build" that is almost certainly a death knell more than the insane wizardry part. My experience:
git clone .../ancient-codebase.git
cd ancient-codebase
./gradlew # <-- oh, the wrapper, so it will download the version it wants, hazzah!
for _ in $(seq 1 infinity); do echo gradle vomit you have to sift through; done
echo 'BUILD FAILED' >&2
exit 1
I dislike Gradle as much as you probably do, but between Maven and Gradle, the one that "vomits" stuff on the command line is definitely Maven.
Gradle errs by going too far to the other end: it just doesn't log anything at all, even the tasks that are actually being run (vs skipped... do you know how to get Gradle to show them?? It's `gradle --console=plain`, so obvious!! Why would anyone complain about that, right?!) or the print outs you add to the build to try to understand what the heck is going on.
Having worked with Maven and Gradle, I'd say Gradle was worse in the average case, but better in the worst case. There are way more Gradle projects with unnecessary custom build code because Gradle makes it easy to do.
On the other hand, when builds are specified in a limited-power build config language, like POM, then when someone needs to do something custom, they have to extend or modify the build tool itself, which in my experience causes way more pain than custom code in a build file. Custom logic in Maven means building and publishing an extension; it can't be local to the project. You may encounter projects that depend on extensions from long-lost open source projects, or long-lost internal projects. On one occasion, I was lucky to find a source jar for the extension in the Maven repository. It can be a nightmare.
The same could happen with Gradle, since a build can depend on arbitrary libraries, but I never saw it in the wild. People depended on major open-source extensions and added their own custom code inside the build.
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.
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.)
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
Sure. But adding ability to self-modify the build drastically increases the complexity of a build tool. Maven developers decided that they want to avoid that.
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.
1: I believe that you encountered errors, programming is packed to the gills with them, but correlation is not causation in that just because it did not immediately work in your setup does not mean it's impossible or forbidden
My problem with gradle is that they keep making breaking changes for low value things like naming of options, so I have to chase deprecation warnings, and can never rely on a distro supplied gradle version
Gradle devs, please get over yourself and stay backward compatible.
Not to defend Gradle too much, but Groovy is a superset of Java. So if you want, you can just use the regular Groovy dialect and then write Java in your build scripts, it should work.
This is not entirely a solution though, because Gradle's APIs are fairly complicated and change regularly.
(Nitpick, but it’s just a “superficial” superset. The biggest difference is probably doing “multi-methods”, aka the runtime type of an argument deciding which method implementation to call vs java’s static overload resolution.)
The article describes this as a "monobloc" air-to-water heat pump. Monobloc means that the compressor, fan, and all the refrigerant are entirely sealed within the outdoor unit, and it just sends a loop of water (or water w/ glycol in it) into the house, where it can warm or cool an insulated buffer tank that effectively stores the hot or cold water for use in heating, cooling, and domestic hot water.
One of the things we hope http://TipTheWeb.org/ will be good for is offering a way for creators of open source tools and useful web services to get money from the people who use what they've created, especially for things that would be hard to build a full business around, but which still have significant value.
Much of what's great about the Web is exactly that: valuable, published for free access, not the basis of a full-time business, yet definitely worth supporting.
If publishers can get direct financial support from their audience, they wouldn't need to overdo things with ads, and they'd focus more on providing the best possible experience for that audience. Better for everyone.
It's a concept that has been around in various forms for some time but doesn't seem to have gained much traction anywhere. As well as a tip everywhere system I assume your letting publishers after they have claimed their site to push the tips with buttons on their site?
I don't think I would be inclined to ever tip unless I knew that the author has a presence on the tipping service so I knew they were actually going to claim the tips. Wonder to if a reverse model, similar to a kickstarter would work, as in an author proposes a piece of content they will put some time into a produce if they get some upfront commitment of tips.
Well, I wouldn't call it a "market", exactly. But people spend money on plenty of things they don't need to. And if no one supports all the great stuff people work on and put up for free on the Web, then we'll just get more and more obnoxious advertisements and more crazy schemes from big businesses.
At TipTheWeb (see my comments above), we think that by supporting the publishers of the stuff you like online, you're helping to make the Web a place that's more valuable to you. We all want more of the good stuff and less of the crap. If you tip a blog post that you like 10 cents, then not only does the publisher of that blog make a little money, but they also get some information about which of the stuff they write is valuable to their readers. This is a feedback loop that's missing from advertisement-driven publishing, where they get the ad impression regardless of whether you like the content.
TipTheWeb ( http://tiptheweb.org/ ) is a new (non-profit!) service that just came out of private beta a few months ago- it has no fees for tippers or publishers, and passes 100% of claimed tips to web publishers via monthly awards. And TipTheWeb doesn’t require a subscription or any kind of ongoing commitment. Both flattr and Readability take big cuts of the money before it gets to publishers. In addition to working with popular publishing platforms and independent websites, TipTheWeb allows multi-contributor sites, like multi-author blogs, to add simple metadata to their pages so that tips can go directly to the authors of the content being tipped.
TipTheWeb ( http://tiptheweb.org/ ) lets you tip almost anything, as long as it is free to access. When a publisher claims their site, they'll find the tips waiting for them. (If tips go unclaimed for a really long time, they get returned to the tipper's account).
