Alright, let's break down what's going on here and fix this step by step. The core issues stem from how Maven handles different module types and dependency resolution—your IDE can find the code during development because it adds all modules to the classpath, but Maven strictly follows dependency declarations when packaging.

1. Understand the Root Problems #

• Pom-type modules (C, D, E) are only for aggregation or inheritance—they don't contain any executable code, so you can't depend on them directly. Maven will ignore them when building your B jar.
• War-type modules (F, G, Example1, Example2) aren't designed to be reused as libraries by default. Their compiled classes aren't packaged in a way that other projects can easily consume them.

2. Make War Modules Reusable #

You have two solid options to share code from war modules with B:

Option A: Split War Modules (Recommended Long-Term) #

For each war module (F, G, etc.), split it into two submodules:

• A jar module (e.g., F-core) that holds all reusable code (business logic, utilities, shared classes)
• A war module (e.g., F-web) that depends on F-core and only contains web-specific files (servlets, JSPs, web.xml)

This way, your B project can depend directly on the F-core jar, which is purpose-built for reuse.

Option B: Attach Classes from War as a Jar (Quick Fix) #

If you don't want to restructure modules right now, configure the Maven War Plugin in each war module's pom.xml to create an extra jar with just its compiled classes:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <version>3.3.2</version>
      <configuration>
        <!-- Generates an additional jar with your module's classes -->
        <attachClasses>true</attachClasses>
      </configuration>
    </plugin>
  </plugins>
</build>

Then, in B's pom.xml, depend on this attached jar using the classifier tag:

<dependency>
  <groupId>your.group.id</groupId> <!-- Match your parent project's groupId -->
  <artifactId>F</artifactId>
  <version>1.0.0</version> <!-- Match your project's version -->
  <classifier>classes</classifier>
</dependency>

3. Fix B's Dependency Declarations #

Never add pom-type modules (C, D, E) as dependencies in B. Instead, depend on the actual jar artifacts under them—either the split *-core jars from Option A, or the classified jars from Option B.

4. Verify Module Aggregation in Parent Poms #

Double-check that your parent modules correctly list their submodules to ensure Maven builds everything in the right order:

• In parent A's pom.xml:

  <modules>
    <module>B</module>
    <module>C</module>
    <module>D</module>
  </modules>
  

• In C's pom.xml:

  <modules>
    <module>F</module>
    <module>G</module>
    <module>Example1</module>
    <module>Example2</module>
  </modules>
  

• In D's pom.xml:

  <modules>
    <module>E</module>
  </modules>
  

5. Package B as an Executable Jar (If Needed) #

If your B module is a standalone GUI app, you need to package it with all dependencies included. Use the Maven Shade Plugin for this—add this to B's pom.xml:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <version>3.4.1</version>
      <executions>
        <execution>
          <phase>package</phase>
          <goals>
            <goal>shade</goal>
          </goals>
          <configuration>
            <transformers>
              <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                <!-- Replace with your GUI's main class path -->
                <mainClass>com.yourpackage.MainGUI</mainClass>
              </transformer>
            </transformers>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

6. Build the Entire Project from the Root #

Always run build commands from the parent project (A) to ensure all dependencies are built and installed locally before B is packaged:

mvn clean package

This guarantees Maven builds C, D, their submodules, and finally B—so B has access to all required artifacts.

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