Hacker News new | ask | show | jobs
by exabrial 574 days ago
Use Maven profiles:

* compile only

* compile/test only

* compile/install jar only, skip source/javadoc packages

* checkstyle only

* static analysis only

* code coverage only

* Skip PGP (you DO check your artifact signatures, right?)

The beauty of this is you can create a corporate super pom that defines all of these for you and they can be inherited by every project in your org.

Finally, if you have a large multi-module project, run with -T2C to parallel-ize module builds. If your tests are written in a sane/safe manner: -DuseUnlimitedThreads=true -Dparallel=classes -DforkCount=2C will also give you a major boost.

We have a giant code base (500,000 SLOC) with 28 maven modules, and a full compile and install takes less 40 seconds with compile/install only. You often don't need to do a full build, but even with tests thats about 3 mins on a M3 Max.

2 comments

I don't think anyone checks their artifact signatures. I've changed signatures several times over the past few years (every time I get a new laptop I forget to copy over my keys) and haven't heard a peep from anyone using my open source libraries who actually noticed the change
We notice and costs several hours per month to handle. A malicious party can slip through, single contributor software is classified as a high risk but XZ utils were not classified as such so we would have missed the Jia Tan incident.
Alas, I'm stuck with Gradle. And not a simple example of the species, either.
I think thats the major issue I have with Gradle in large orgs: it doesn't lend itself to reuse, but I don't blame it either: it's not really meant to do that.

I'm dating myself, but 20 years ago, we had Ant. It was very much a blunt hammer like CMake. Maven came along and was like "how about we choose a definitive way to organize projects, make that repeatable". You lose flexibility but gain speed/reuse.

I see Gradle more of a replacement for Ant than Maven in this regard. Infinite flexibility, at the cost of speed/reuse.

>it doesn't lend itself to reuse, but I don't blame it either: it's not really meant to do that.

Only if you keep writing more logic into build.gradle.kts.

Writing custom Gradle plugins has been the standard and recommended way to configure your projects for years now. Aside from a few footguns (lol extensions not being resolved at configuration time and needing providers everywhere), it allows you to mostly skip configuration steps.

> You lose flexibility but gain speed/reuse.

Its actually: You lose major flexibility AND all your speed but gain reuse.