Eliminate odlparent managed versions#2612
Conversation
// TODO: complete JIRA: LIGHTY-427 Signed-off-by: Ivan Hrasko <ivan.hrasko@pantheon.tech>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes explicit version declarations for several dependencies and plugins across multiple POM files to rely on centralized management. Feedback highlights that removing plugin versions in "lighty-parent" may result in unmanaged versions since the project imports rather than inherits from "odlparent". Furthermore, a potential version mismatch was identified for SLF4J and Log4j, as their version properties remain in use within the SpotBugs plugin configuration despite being removed from the primary dependency definitions.
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-compiler-plugin</artifactId> | ||
| <version>3.15.0</version> | ||
| </plugin> | ||
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-clean-plugin</artifactId> | ||
| <version>3.5.0</version> | ||
| </plugin> |
There was a problem hiding this comment.
Removing the versions for maven-compiler-plugin and maven-clean-plugin from pluginManagement requires that these versions are managed by a parent POM. However, lighty-parent inherits from lighty-minimal-parent, which does not inherit from odlparent (it only imports it for dependency management). Since pluginManagement is not inherited via BOM imports (scope=import), these plugins will now have unmanaged versions.
Additionally, this change is inconsistent with other plugins in the same section (e.g., maven-resources-plugin at line 84 and maven-jar-plugin at line 89) which still have explicit versions despite also being managed by odlparent.
If the goal is to use odlparent's plugin versions, lighty-minimal-parent should be updated to inherit from it; otherwise, these explicit versions should be retained to ensure build stability.
References
- Plugin versions should be managed either explicitly or via inheritance from a parent POM to ensure build reproducibility and avoid reliance on Maven defaults.
| <dependency> | ||
| <groupId>org.slf4j</groupId> | ||
| <artifactId>slf4j-api</artifactId> | ||
| <version>${slf4j.version}</version> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.logging.log4j</groupId> | ||
| <artifactId>log4j-slf4j2-impl</artifactId> | ||
| <version>${log4j2.version}</version> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.logging.log4j</groupId> | ||
| <artifactId>log4j-core</artifactId> | ||
| <version>${log4j2.version}</version> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.logging.log4j</groupId> | ||
| <artifactId>log4j-api</artifactId> | ||
| <version>${log4j2.version}</version> | ||
| </dependency> |
There was a problem hiding this comment.
The versions for SLF4J and Log4j dependencies have been removed to rely on odlparent management. However, the properties slf4j.version and log4j2.version (defined at lines 32-33) are still present and used in the spotbugs-maven-plugin configuration (lines 222, 227). This creates a risk of version mismatch between the main project dependencies and the plugin's dependencies.
To ensure consistency, consider removing the explicit versions from the SpotBugs plugin dependencies as well (allowing them to be managed by the same BOM) and then removing these properties if they are no longer needed elsewhere.
References
- Dependency versions should be managed consistently across the project to avoid classpath conflicts and version drift between main code and build tools.
1 participant
// TODO: complete
JIRA: LIGHTY-427