Reload All Maven Projects breaks our whole setup.

Bonjour Frédéric,

For Maven projects, IntelliJ treats the POM as the source of truth and rewrites the module descriptors under ...IntelliJIdea2026.2\projects\external_build_system\modules on every Reload All Maven Projects. Any manual per-module SDK tweaks done directly in those XMLs or via the UI are not stable and will be overwritten on reload.

So make sure you have a consistent maven-compiler-plugin configuration with either:

• <release>8</release> / <release>11</release>, or
• <source>1.8</source>, <target>1.8</target> vs <source>11</source>, <target>11</target>

Also configure <encoding>UTF-8</encoding> there.

If the issue remains, please share your pom.xml - or, ideally, the entire project (or a small stripped down version) where I can test this.

To avoid automatic creation of ADDITIONAL_OPTIONS_OVERRIDE, try the following:

1. Open Help | Find Action…, type "registry", and open the Registry… dialog.

2. In the Registry, search for the maven.import.compiler.arguments key:

   

3. Disable that flag.
4. Close the IDE, delete .idea/compiler.xml (or at least the <option name="ADDITIONAL_OPTIONS_OVERRIDE">…</option> block), then start the IDE and Reload All Maven Projects once.

If it doesn't help, I will definitely need your project to investigate what happens.

Hi Arina, thanks for your reply. I tried your solution but nothing works when in reload all maven projects. All my "punching-controler-* projects are reassigned to SKD11 but i want jdk 1.8 ! 

I can't send you the entire project (it's too large). However, here is an excerpt from my project tree containing only the pom.xml files.  I hope this helps you troubleshoot the issue. Thanks a lot.

Upload id: 2026_08_17_9GNMmmg38coC5VndKRKTgb (file: Kelio-poms.zip) 

Hi Frédéric,

Thanks for the ZIP with the POMs, that made it much clearer what’s going on.

From the tree you sent:

• The root ergo-software-racine/pom.xml configures maven-compiler-plugin with <release>11</release> – so the “global” compiler toolchain for the whole build is JDK 11.
• Under git-src/punching/production/pom.xml you override the compiler plugin for punching with <source>1.8</source> / <target>1.8</target>, and some child modules have their own maven-compiler-plugin blocks with even older targets (1.4, 1.5, 1.6, 1.7, 1.8) or newer ones (16, 17) depending on the module.

IntelliJ 2026.2 now does two things on Reload All Maven Projects:

1. Takes the SDK for Maven modules from Maven, not from manual per-module edits.
   Because your top-level POM effectively says “compile with JDK 11” (via <release>11</release>), IDEA maps Maven modules back to the project JDK 11 on each reload. The per-module SDKs you set by hand in Project Structure are no longer treated as authoritative for Maven modules, so they get overwritten. That’s why all the punching-controleur-* modules jump back to SDK 11.
2. Treats source/target as language level, not as “which JDK installation to use”.
   The 1.4/1.6/1.8 values in the various maven-compiler-plugin configs are respected for language/bytecode level, but they do not mean “use a JDK 1.4/1.6/1.8 installation for this module” – they mean “compile with JDK 11, targeting this older bytecode level”. That’s why changing those values alone doesn’t give you a stable JDK 8 SDK in the IDE.

So with the current importer, there’s no way to keep manual “JDK 1.8 SDK” assignments for Maven modules stable across a Maven reload: the Maven model always wins and re-applies JDK 11.

Given your constraints, you effectively have two options:

1: Let everything compile with JDK 11, keep old target values

This is the least intrusive and closest to what Maven already describes:

• Keep your existing maven-compiler-plugin config (<source>/<target> or <release>) as-is.
• Accept that IntelliJ will use JDK 11 SDK for those modules, while still generating 1.4/1.6/1.8 bytecode where you’ve configured that.
• Verify after reload that the language level of punching-controleur-* modules is set correctly (8 or below). As long as that’s true, the fact that the SDK is “11” is usually harmless and matches what mvn does.

If the build errors you mentioned (“UTF-8” / JDK 1.8 errors) only appeared because of the bad ADDITIONAL_OPTIONS_OVERRIDE block in compiler.xml, then once that part is under control this setup should work, even with SDK 11.

2: Model the multiple JDKs in Maven with toolchains, and delegate builds to Maven

If certain modules must be compiled by a real JDK 8 (not just target 1.8 under JDK 11), that information needs to live in Maven, not only in IDEA:

1. Configure Maven toolchains (in ~/.m2/toolchains.xml) with entries for JDK 8 and JDK 11.
2. In the POMs where you need JDK 8 (for example, git-src/punching/production/pom.xml or specific punching-controleur-* POMs), wire maven-toolchains-plugin + maven-compiler-plugin so Maven itself selects the JDK 8 toolchain for those modules.
3. In IntelliJ, switch to Build, Execution, Deployment | Build Tools | Maven | Runner → “Delegate IDE build/run actions to Maven”. Then “Build Project” runs Maven, which will use the correct toolchain JDK even if the module’s SDK in Project Structure still shows 11.

This gives you reliable JDK selection for the actual compilation without fighting the IDE’s rewrite of module SDKs.