Hey, let’s add a new module to this Spring Boot project. What could possibly go wrong?

A lot! Build completed with 100 errors and 0 warnings in 2 sec. The errors were not even in a module we worked on. They were in common, the shared DTO module that has compiled fine for years.

What followed was an afternoon of archaeology through IntelliJ caches, Maven authentication and my own shell. Here are the six traps, in the order we fell into them.

The 100 Errors Are A Lie

Exactly 100 errors should make you suspicious the way “exactly 99.9% uptime” should. javac stops counting at 100 by default, so the build window is showing you a ceiling, not a result. The real count was 124, we had to re-run with -Xmaxerrs 10000 to even see it, all cannot find symbol, all on Lombok-generated getters.

One flag reproduces the whole disaster. We compiled the same 87 files with javac 21:

# with annotation processors from the classpath: compiles clean
javac -d out -cp @cp.txt @sources.txt

# without them: exactly 100 errors, welcome to my afternoon
javac -proc:none -d out -cp @cp.txt @sources.txt

So the module was being compiled without Lombok. The question was why an IDE that had “worked” for weeks would suddenly do that.

The Import Model Was Hollow

IntelliJ does not build against your pom.xml. It builds against an imported model it keeps under ~/.cache/JetBrains/IntelliJidea<version>/projects/<project-hash>/. Ours had a surprise: common listed exactly one dependency, org.jetbrains:annotations, which happens to be the only artifact in the parent pom with a hardcoded version. The whole project model carried 20 libraries. A healthy import of this project has 635.

Every dependency that gets its version from a BOM, so basically everything via spring-boot-starter-parent, was missing. The model had been quietly broken since an IDE upgrade from 2025.3 to 2026.1, and nothing noticed. Incremental compilation never needed to recompile common against the crippled model, so the floor held. The new module forced a fresh compile and the floor gave way. Two weeks of standing on a cache, essentially.

Reload All Does Not Reload All

We hit Reload All Maven Projects. The log said incremental=true and Workspace model loaded from cache, and the model files on disk kept their two-week-old timestamp. We hit File > Invalidate Caches, which cleared indexes and good vibes, but not the Maven model.

Only this helped, with the IDE fully closed:

# the caches that Invalidate Caches does not invalidate
rm -rf ~/.cache/JetBrains/IntelliJidea2026.2/projects/<project-hash>/project-model-cache
rm -rf ~/.cache/JetBrains/IntelliJidea2026.2/projects/<project-hash>/external_build_system

On the next open IntelliJ did a real from-zero import: 607 libraries, Lombok back on the classpath. Problem solved…

The IDE Has No Shell

With the model healed, the sync still complained: 403 Forbidden from the company artifactory. But the command line was fine! Note the quotes around “fine”.

Our settings.xml authenticates with ${env.ARTIFACTORY_USER} and ${env.ARTIFACTORY_TOKEN}. An IntelliJ started from the launcher, as convenient as it is, is a GUI child process. It gets a non-interactive shell and most .bashrc have a guard at the top to exit in such a case. Result: the launcher never sources your .bashrc, so both variables resolve to nothing inside the Maven import, and the artifactory answers 403. The command line worked because every dependency was already in the local repo. Nobody had actually talked to that server in weeks.

We tried the “Environment variables” field under Build Tools > Maven > Runner. But the field seems to apply only to running Maven goals, not to the import. Thanks for nothing.

The last resort fix: put the credentials as plain values into ~/.m2/settings.xml. Not pretty, but it works.

You could of course move your variable exports in .bashrc to before this guard:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Alternatively modify ~/.local/share/applications/jetbrains-idea.desktop to include your environment values. Just make sure you edit the file you created, not the one Toolbox generates: Toolbox happily overwrites its own entries on every upgrade, while yours survives. Mine still says 2025.3.2 and launches 2026.2.

Maven Keeps A Grudge

Fix the credentials, re-run the sync, still failing? Maven remembers failed transfers in files ending in .lastUpdated and refuses to retry them “until the update interval has elapsed”. After an afternoon of 403s we had 1,730 of those markers lying around:

# these files only record past pain, delete them
find ~/.m2/repository -name '*.lastUpdated' -delete

Or use the link IntelliJ provides but buries under a load of maven output to re-run with -U.

Your Terminal Is Also Lying

My favorite one: I had my AI test the token. It got a 401 and confidently declared it expired. It was not. I re-generated it anyway. Several times.

The test shell was non-interactive as it is for IntelliJ. .bashrc has the usual early-return guard for non-interactive shells, so it never reached the export ARTIFACTORY_TOKEN line, and my shell inherited some stale token value from a parent process. The fresh, valid, one-day-old token was sitting in .bashrc the whole time. I spent a happy while proving a working token was broken.

And Now?

Well, it works for now. But I’m sure tomorrow it won’t. See you then.