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.

Hi Arina, thanks for your detailed analysis of the tree structure of our pom.xml files and for your two solutions.  

Option 1 (JDK11) isn't possible because JDK11 can't produce 1.4 or 1.6 bytecode, so we need a real JDK8.  

I went ahead with solution 2 using toolchains and magic workaround.

1. I set up my jdk version in my parent production/pom.xml

<!-- Toolchain -->
<jdk8-vendor>adoptopenjdk</jdk8-vendor>
<jdk8-version>1.8</jdk8-version>

<jdk11-vendor>temurin</jdk11-vendor>
<jdk11-version>11</jdk11-version>

<jdk17-vendor>temurin</jdk17-vendor>
<jdk17-version>17</jdk17-version>

my toolchains.xml configuration

<?xml version="1.0" encoding="UTF-8"?>
<toolchains>
 <toolchain>
   <type>jdk</type>
   <provides>
     <version>1.8</version>
      <vendor>adoptopenjdk</vendor>
   </provides>
   <configuration>
     <jdkHome>D:\dev\jdk\openjdk-8u332-b09</jdkHome>
   </configuration>
 <toolchain>
   <type>jdk</type>
   <provides>
     <version>11</version>
      <vendor>temurin</vendor>
   </provides>
   <configuration>
     <jdkHome>D:\dev\jdk\jdk-11.0.14.1+1</jdkHome>
   </configuration>
 </toolchain>
 </toolchain>
   <toolchain>
       <type>jdk</type>
       <provides>
           <version>17</version>
            <vendor>temurin</vendor>
       </provides>
       <configuration>
           <jdkHome>D:\dev\jdk\jdk-17.0.1</jdkHome>
       </configuration>
   </toolchain>
</toolchains>

2. Next, i defined the children pom.xml with toolchains by using specific jdk version following their usage, 

ie for punching-commun-parent pom.xml with jdk8

<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.6</source>
                <target>1.6</target>
            </configuration>
        </plugin>
        <!-- Utilisation d’une toolchain JDK8 pour compiler pour être compatible avec le vieux code java -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-toolchains-plugin</artifactId>
            <version>${maven-toolchains-plugin.version}</version>
            <executions>
                <execution>
                    <id>select-jdk-8</id>
                    <phase>validate</phase>
                    <goals>
                        <goal>toolchain</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <toolchains>
                    <jdk>
                        <!--  on hérite des propriétés du parent production/pom.xml qui définit la version du jdk à utiliser -->
                        <version>${jdk8-version}</version>
                        <vendor>${jdk8-vendor}</vendor>
                    </jdk>
                </toolchains>
            </configuration>
        </plugin>
    </plugins>
</build>

ie for punching-linux-controller pom.xml with jdk17

<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.0</version>
            <configuration>
                <fork>true</fork>
                <source>17</source>
                <target>17</target>
                <meminitial>128m</meminitial>
                <maxmem>1024m</maxmem>
                <encoding>UTF-8</encoding>
                <failOnError>true</failOnError>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-toolchains-plugin</artifactId>
            <executions>
                <execution>
                    <id>select-jdk-17</id>
                    <phase>validate</phase>
                    <goals>
                        <goal>toolchain</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <toolchains>
                    <jdk>
                        <version>17</version>
                    </jdk>
                </toolchains>
            </configuration>
        </plugin>

3. i added a workaround in my compile-perc profile (hich was messing with the compilation chain and Maven reload) with the magic idea.version property for blocking this profil during my relaod maven 

<profile>
        <id>compile-perc</id>
        <activation>
            <!-- Le profil sera automatiquement utilisé en cas de présence de ce fichier dans un projet -->
            <file>
                <exists>perc.compile</exists>
            </file>
            <!-- IntelliJ définit généralement cette propriété lors de l'import Maven -->
            <property>
                <name>!idea.version</name>
            </property>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <!-- Compilation en utilisant les jar de la PERC pour s’assurer de la compatibilité du code avec le Concentrateur/Visio 1 -->
                    <!-- pour tous les projets qui sont une dépendance du jar final exécuté sur cette plateforme -->
                    <!-- La jvm PERC n’est pas une jvm standard et si on utilise un jdk standard pour compiler, on peut se retrouver avec du code non exécutable sur la target -->
                    <executions>
                        <!-- On supprime la compilation par défaut, pour ne pas avoir de multiple phase de compilation -->
                        <execution>
                            <id>default-compile</id>
                            <phase>none</phase>
                        </execution>
                        <execution>
                            <id>compile-perc</id>
                            <phase>compile</phase>
                            <goals>
                                <goal>compile</goal>
                            </goals>
                            <configuration>
                                <fork>true</fork>
                                <compilerArgs>
                                    <arg>-bootclasspath</arg>
                                    <arg>${settings.localRepository}/perc/perclib/${perc.version}/perclib.jar</arg>
                                </compilerArgs>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>

        </build>
    </profile>
</profiles>

and now all modules are correctly assigned with the right JDK (1.8, 11, 17) according to their needs after a relaod Maven. This saves me from seeing the compilation delegated to Maven (used only for CI/CD) but not for development.

Thanks for your help

Regards

Great job, Frédéric! This is an excellent solution. 

Thanks for documenting it so clearly👍🏻