Skip to content

annotationProcessorPaths "leak" version from parent to child pom #325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
svpace opened this issue Apr 12, 2025 · 0 comments
Open

annotationProcessorPaths "leak" version from parent to child pom #325

svpace opened this issue Apr 12, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@svpace
Copy link

svpace commented Apr 12, 2025

Affected version

3.14.0

Bug description

Not quite sure if this should be reported here or in the Maven Jira. But as it seems to be related to #180 reporting here first. Please let me know if I should report there.

When a parent POM or pluginManagement defines a set of annotation processors with versions, and the child POM or plugins defines another set of processors without versions (relying on dependencyManagement), the version is inherited from the processor defined at the corresponding position in the list instead of the dependency management.

The following POM shows the issue:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.example</groupId>
	<artifactId>maven-compiler-plugin-issue</artifactId>
	<version>1.0.0-SNAPSHOT</version>

	<properties>
		<maven.compiler.source>17</maven.compiler.source>
		<maven.compiler.target>17</maven.compiler.target>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
	</properties>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.mapstruct</groupId>
				<artifactId>mapstruct-processor</artifactId>
				<version>1.6.3</version>
			</dependency>
		</dependencies>
	</dependencyManagement>
	<build>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-compiler-plugin</artifactId>
					<version>3.14.0</version>
					<configuration>
						<annotationProcessorPaths>
							<path>
								<groupId>org.projectlombok</groupId>
								<artifactId>lombok</artifactId>
								<version>1.18.38</version>
							</path>
						</annotationProcessorPaths>
					</configuration>
				</plugin>
			</plugins>
		</pluginManagement>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<annotationProcessorPaths>
						<path>
							<groupId>org.mapstruct</groupId>
							<artifactId>mapstruct-processor</artifactId>
						</path>
					</annotationProcessorPaths>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

The resulting effective POM end up like this:

    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.14.0</version>
            <executions>
                <execution>
                    <id>default-compile</id>
                    <phase>compile</phase>
                    <goals>
                        <goal>compile</goal>
                    </goals>
                    <configuration>
                        <annotationProcessorPaths>
                            <path>
                                <groupId>org.mapstruct</groupId>
                                <artifactId>mapstruct-processor</artifactId>
                                <version>1.18.38</version>
                            </path>
                        </annotationProcessorPaths>
                    </configuration>
                </execution>

If I omit the groupId from plugins it also inherits it from parent. It feels like Maven's list and non-list merge behavior gets mixed up and it replaces the list but fills in any missing fields.

I am pretty sure that a combine.children or combine.self may workaround this, but the current way fells wrong.

Let me know if you need any more infos.

@svpace svpace added the bug Something isn't working label Apr 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant