elharo commented on issue #203: URL: https://github.com/apache/maven-war-plugin/issues/203#issuecomment-5084915419
### Issue Overview & Context This issue (originally **MWAR-360**) describes a scenario where transitive WAR dependencies are unintentionally overlaid during the build process. The reporter has a project hierarchy of WAR modules utilizing the `<attachClasses>true</attachClasses>` configuration, which produces a `-classes` JAR artifact alongside the standard WAR deployment archive. When project `Level2` depends on `Level1`, and `Level1` depends on `Base`, the `maven-war-plugin` identifies both `Level1` and `Base` as WAR artifacts in the resolved dependency graph. Consequently, the plugin automatically overlays both `Level1` and `Base` into `Level2`. The reporter views this as inefficient and logically incorrect, arguing that `Level1` already contains the necessary assets from `Base`. They propose either introducing a `notOverlayTransitiveWar` flag or modifying the plugin to only process direct dependencies (`project.getDependencyArtifacts()`) rather than the full resolved graph (`project.getArtifacts()`). --- ### Is it still accurate? **Yes, the technical description of the plugin's behavior remains accurate.** The `maven-war-plugin` evaluates the entire resolved dependency graph provided by Maven Core. By default, any artifact in that graph with the `<type>war</type>` packaging is treated as an overlay source and applied to the final web application structure. --- ### Should it be fixed or closed? **It should be closed as "Won't Fix" or "Works as Designed."** #### Reasons to Close: 1. **Architectural Anti-Pattern:** The issue stems from an improper project structure. In Maven, a WAR is a terminal deployment artifact, not a shared library. Making modules depend on WAR artifacts (or their attached `-classes` JARs) to share Java code or resources is an anti-pattern. If code or resources must be shared across multiple web applications, they should be extracted into a separate `<packaging>jar</packaging>` module. The WAR modules can then declare standard dependencies on that shared JAR. 2. **Existing Explicit Configuration:** The `maven-war-plugin` already provides a mechanism to handle complex overlay requirements. Users can define an `<overlays>` block in the plugin configuration to explicitly specify which WARs should be overlaid, dictate their exact order, and define exclusions. Introducing a highly specific `notOverlayTransitiveWar` flag is unnecessary when the configuration block already solves the problem natively. 3. **High Risk of Breaking Changes:** Adopting the reporter's suggestion to switch to `project.getDependencyArtifacts()` would alter the default behavior to only overlay direct dependencies. This would break backward compatibility for numerous projects that intentionally rely on transitive WAR overlays to compose modular applications (e.g., `final-app` $\rightarrow$ `feature-war` $\rightarrow$ `core-theme-war`). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
