elharo commented on issue #181: URL: https://github.com/apache/maven-war-plugin/issues/181#issuecomment-5084897534
### Issue Overview & Context This issue (originally **MWAR-351**) asks whether dependencies declared directly in a WAR module's POM with `<optional>true</optional>` should be included in the packaged `WEB-INF/lib` folder. The reporter argues that according to the Maven documentation on optional dependencies: * If Project A depends on Project B as `<optional>true</optional>`, Project B is on Project A's local build classpath. * If Project X depends on Project A, Project B is omitted transitively. * Since the WAR project *is* Project A, the reporter contends that optional direct dependencies should be packaged into `WEB-INF/lib`. --- ### Is it still accurate? **Yes, the issue accurately describes Maven's long-standing behavior.** The `maven-war-plugin` intentionally filters out any dependency flagged as `optional` (or `provided`) when assembling `WEB-INF/lib`. --- ### Should it be fixed or closed? **It should be closed as "Not a Bug / Works as Designed."** #### Reasons to Close: 1. **Misuse of the `<optional>` Mechanism:** In Maven, the primary artifact produced by a `war` module is a deployment archive, not a reusable library dependency. Marking a direct dependency as `<optional>true</optional>` inside a WAR POM is a conceptual contradiction: * Packaging a dependency into `WEB-INF/lib` means it is required at runtime for that application instance. * Marking a dependency as `optional` explicitly tells Maven's dependency tree resolver *not* to treat the artifact as a required runtime bundle for execution. 2. **Core Maven Resolution Contracts (`project.getArtifacts()`):** `maven-war-plugin` filters dependencies based on `artifact.isOptional()`. If an artifact is marked optional, Maven treats it as excluded from standard runtime distribution packaging. 3. **Misapplying EJB/WAR Packaging Workarounds:** The reporter's use case stems from combining an EJB server app and an `ejb-client` module inside a single WAR project to avoid leaking server-side transitive dependencies to clients. The idiomatic Maven solution for this scenario is using standard Maven profiles, distinct modules, or explicit `<exclusions>` in client POMs—not abusing `<optional>true</optional>` on direct dependencies of a WAR artifact. -- 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]
