Maven插件能否继承项目构建依赖？避免重复配置依赖

Absolutely, you can make your Maven plugin inherit the project's build dependencies—no need to duplicate them in the plugin's configuration. Here's how to do it properly, based on your use case as a Java-to-other-language transpiler that needs reflection access to compiled classes:

Solution 1: Use Maven's API to Build a Custom ClassLoader (Recommended) #

Maven plugins run in their own isolated classloader by default, which is why they can't see your project's dependencies out of the box. The cleanest fix is to use Maven's built-in APIs to collect your project's compile/runtime dependencies, then create a custom classloader that includes those dependencies plus your project's compiled classes.

Here's a concrete implementation for your Mojo:

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Component;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;
import org.apache.maven.project.MavenProject;
import org.apache.maven.artifact.Artifact;

import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.ArrayList;
import java.util.List;

@Mojo(name = "transpile", defaultPhase = LifecyclePhase.PROCESS_CLASSES)
public class ClassTranspilerMojo extends AbstractMojo {

    // Inject the current Maven project
    @Parameter(defaultValue = "${project}", readonly = true, required = true)
    private MavenProject project;

    // Path to your project's compiled classes
    @Parameter(defaultValue = "${project.build.outputDirectory}", readonly = true)
    private File outputDirectory;

    @Override
    public void execute() throws MojoExecutionException {
        try {
            // Collect all URLs needed for the classloader: compiled classes + project dependencies
            List<URL> classpathUrls = new ArrayList<>();
            
            // Add the project's compiled classes directory first
            classpathUrls.add(outputDirectory.toURI().toURL());

            // Resolve and add compile/runtime scope dependencies
            List<Artifact> projectDependencies = project.getArtifacts();
            for (Artifact artifact : projectDependencies) {
                String scope = artifact.getScope();
                if (Artifact.SCOPE_COMPILE.equals(scope) || Artifact.SCOPE_RUNTIME.equals(scope)) {
                    classpathUrls.add(artifact.getFile().toURI().toURL());
                }
            }

            // Create a custom classloader (parent is the plugin's classloader to avoid missing plugin classes)
            URLClassLoader customClassLoader = new URLClassLoader(
                classpathUrls.toArray(new URL[0]),
                getClass().getClassLoader()
            );

            // Now use this classloader to load your target classes for reflection
            // Example: Iterate over .class files in outputDirectory, load each with customClassLoader.loadClass(...)
            // ... your transpilation logic here ...

        } catch (Exception e) {
            throw new MojoExecutionException("Failed to transpile classes", e);
        }
    }
}

Why this works: #

• You're directly reusing your project's existing dependency declarations—no duplication needed.
• The custom classloader isolates your project's classes/dependencies from the plugin's own classpath, preventing version conflicts (e.g., if your plugin uses a different SLF4J version than the project).
• It covers both compile and runtime dependencies, which is critical since your compiled classes may reference runtime-scoped libraries.

Solution 2: Adjust the Plugin's Classpath Scope (Simpler but Risky) #

If you want a quicker fix without writing custom classloader code, you can configure Maven to include the project's compile/runtime dependencies in the plugin's classpath. Add this to your plugin configuration in the project POM:

<plugin>
  <groupId>myplugins</groupId>
  <artifactId>my-custom-plugin-that-processes-classes</artifactId>
  <configuration>
    <!-- Include project's compile-scoped dependencies in the plugin's classpath -->
    <classpathScope>compile</classpathScope>
  </configuration>
</plugin>

Or use runtime if you need runtime dependencies too.

Caveats: #

• This merges the plugin's classpath with the project's classpath, which can cause version conflicts. For example, if your plugin relies on SLF4J 1.7 and the project uses SLF4J 2.0, you'll hit NoClassDefFoundError or ClassCastException issues.
• It's less flexible than the custom classloader approach, as you can't fine-tune which dependencies are included.

Key Considerations #

• Dependency Scopes: Make sure to include both compile and runtime scopes—your compiled classes may reference runtime-only dependencies (like JDBC drivers) that aren't in the compile classpath.
• Snapshot Dependencies: If your project uses snapshot artifacts, ensure your plugin leverages Maven's built-in resolution logic (as shown in Solution 1) to pull the latest snapshot versions correctly.
• Resource Loading: If your transpilation logic needs to read resources from the project's classpath, use the custom classloader's getResource() or getResourceAsStream() methods instead of the default classloader.

With Solution 1, you can completely remove the duplicate <dependencies> block from your plugin configuration, and your transpiler will automatically have access to all the classes and dependencies it needs.

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