JDK10下Java Modules环境Spring Boot项目Maven构建报错咨询

Hey there, let’s dig into this confusing issue you’re hitting with your Spring Boot + Java Modules project. I’ve run into similar quirks with Java Modules and Maven Surefire before, so let’s break down why this is happening and whether it’s an oversight, a plugin quirk, or a Spring bug.

Why the Error Happens (Even Without Custom Test Classes) #

First off, even though you don’t have any hand-written test classes, here’s what’s going on:

• When your project has a module-info.java, Maven treats it as a Java Module instead of a traditional classpath project. This changes how class visibility and scanning work entirely.
• Spring Boot’s dependencies (like Spring Web or Actuator) bring in test-related auto-configurations under the hood. The Maven Surefire plugin, even without explicit test classes, might trigger Spring’s test context initialization logic when processing modules.
• In a module environment, Spring’s test context scanner can’t automatically find your @SpringBootApplication (which includes @SpringBootConfiguration) unless your module explicitly allows access to your main application package. Module boundaries restrict class visibility by default—so Spring can’t peek into your module’s code unless you explicitly export it or open it.

Why Removing module-info.java or Using -DskipTests Fixes It #

• Removing module-info.java: This switches your project back to a traditional classpath setup, where there are no visibility restrictions. Spring can freely scan all classes on the classpath and find your configuration without issues.
• -DskipTests: This skips the entire test phase entirely. Since Surefire doesn’t run any test-related initialization, the Spring test context scanner never gets triggered—so the error never pops up.

Is This an Operation Mistake, a Surefire Bug, or a Spring Bug? #

It’s a mix of module configuration nuances and potential compatibility gaps, not necessarily a "mistake" on your part:

1. Likely Module Configuration Oversight #

The most common culprit is a missing or incomplete module-info.java setup. For Spring’s test context to find your configuration, you need to:

• Declare requires for all necessary Spring Boot modules.
• Export or open your main application package to Spring’s test-related modules so they can scan your @SpringBootApplication class.

Example corrected module-info.java:

module com.mydeveloperplanet.myfabric8planet {
    // Declare required Spring modules
    requires spring.boot;
    requires spring.boot.autoconfigure;
    requires spring.web;
    requires spring.boot.actuator;
    
    // Export your main package to Spring test modules
    exports com.your.main.package to spring.boot.test, spring.boot.autoconfigure;
    
    // If you're using component scanning, you might need to open packages too
    opens com.your.main.package to spring.context, spring.boot.autoconfigure;
}

2. Potential Maven Surefire Plugin Compatibility #

Older versions of the Surefire plugin have known quirks with Java Modules, especially when handling projects without explicit test classes. The plugin might incorrectly trigger test context initialization even when there’s nothing to test. Upgrading to a newer version (like 3.2.5 or later) often fixes these module-related edge cases.

3. Spring Boot Module Scanning Edge Case #

While less likely, there could be a minor edge case in Spring Boot’s test auto-configuration when running in a module environment without explicit test classes. Spring’s scanner might not properly handle module boundaries in this specific scenario.

Fixes to Try (Beyond Skipping Tests) #

1. Fix Your module-info.java: Follow the example above to export/open your main package and declare all required modules.
2. Upgrade Maven Surefire Plugin: Update your pom.xml to use a newer version of Surefire:

   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-surefire-plugin</artifactId>
               <version>3.2.5</version>
           </plugin>
       </plugins>
   </build>
   

3. Add a Dummy Test Class: Create an empty test class with explicit configuration to guide Spring’s scanner:

   package com.your.main.package;
   
   import org.springframework.boot.test.context.SpringBootTest;
   
   @SpringBootTest(classes = YourMainApplication.class)
   public class DummyTest {
       // Empty test to trigger correct context initialization
   }
   

   This gives Surefire a test class to process, and explicitly tells Spring where your configuration lives, bypassing the auto-scanning issue in modules.

Final Takeaway #

This is mostly a module visibility issue paired with potential Surefire plugin behavior in module environments. It’s not a clear-cut "bug," but rather a nuance of working with Java Modules and Spring Boot together. Fixing your module-info.java or upgrading Surefire should resolve the error without needing to skip tests or remove the module descriptor.

内容的提问来源于stack exchange，提问作者mydeveloperplanet