Different builds for ejb-client optional with parent

I think the underlying issue is a possible false assumption.
The WAR plugin assumes that all of it's dependencies will be resolved to artifacts from it's pom. But in a multimodule build, some artifact's such as an attached an attached ejb-client artifact are not resolved from the war's dependency list. It's already attached to the project. Due to this declaring the ejb-client as optional has no effect.

I will attach the patch we are using as a candidate patch. The patch iterates the dependency list to develop an optional artifacts sub-list. It then iterates the optional artifacts list and ensures the resolved artifacts reflect the optional attribute.

Patch provides solution for version 2.0.2 of plugin.

Fixed the the relative path in the previous patch file

• Index: maven-war-plugin-2.0.2/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
  + Index: src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java

Candidate patch for 2.1-alpha-1

Test Steps:

1) Extract mytime.zip

2) set JAVA_HOME to jdk 1.5 or higher (the test project uses ejb annotations)

3) cd into mytime-ejb directory and execute mvn clean install. Build should be successful. mytime-ejb-2.0-SNAPSHOT.jar and mytime-ejb-2.0-SNAPSHOT-client.jar are installed to local repo.

4) Next, cd to the mytime-war project and run mvn clean install. Build should be successful. mytime-war-2.0-SNAPSHOT.war is installed to local repo.

5) Next, cd to mytime-ear project and run mvn clean install. Build should be successful and mytime-ear-2.0-SNAPSHOT.ear is installed to local repo.

6) Validate the following regarding the generated artifacts. Validation point: mytime-war does not contain a WEB-INF/lib directory and does not contain the mytime-ejb-client. This is the correct behavior. Validation point PASSES

7) Next, cd to the mytime project (the parent and aggregator of the other projects) Run mvn clean install. Note successful builds from each project.

8) Validate the following regarding the generated artifacts. Validation point: mytime-war does not contain a WEB-INF/lib directory and does not contain the mytime-ejb-client. This is the correct behavior. Validation point FAILS

Hi Tim,

Thanks for the extensive info. I'm flagging this one as to be fixed for the next alpha. I think that your patch is a bit weird so I'll investigate how it can be improved.

Note sure it's a WAR issue. The optional flag is not passed to the war plugin, period. You will have the same kind of issue with the EAR if you put the ejb-client optional

This is a Maven core issue.

I guess you need this for the manifest? Otherwise can't you put it provided?

Hi Stephane, I agree the real problem is beyond the war plugin (I was hoping for a tactical solution with these patches.)

I'd like to propose the real issue is that Artifact should not have Dependency attributes as part of the object model. After all, a Dependency is not an Artifact but rather states the need (or not) for an Artifact.
IMO, an Artifact should not have a scope. An Artifact should not have a versionRange (although available versions is fine), and an Artifact can not be "optional" - it simply is. Dependencies are optional, have version ranges and scope. As you point out, in a mutli-module build which ever project resolves an "in common" dependency first will be the one to say if the artifact is optional, etc.

I wonder if Jason, Brett, John, et al would agree or not. Even if they did agree it would take many releases to change this.
I am hoping for now at least the war plugin could look at the project's Dependency list for the Dependency->optional attribute and not "trust" the Artifact->optional attribute.

SN> You will have the same kind of issue with the EAR if you put the ejb-client optional
Yes, I think the same issue would exist. But it's not an issue for our scenario, I guess i'd label this as "skinny war with attached ejb-client".

SN> I guess you need this for the manifest? Otherwise can't you put it provided?
Yup, pretty much following this advice: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html
I'll add we really don't want to build our manifests manually. I'd rather continue with forking the war plugin I think.

Are you happy if I provide a way to build the manifest in a more elegant way?

Declaring the dependency as provided+optional is such as mess ... I was more thinking of a declarative way of doing this in the war plugin itself, a la ArtifactItem of the dependency plugin.

WDYT?

I wanted to check with the team I work with about this. They basically said they are not against this, but they would like to know more about how this change would be implemented before 'giving a thumbs up' at least for our team here.

On a different but potentially related noete: I can say that we ran into a seemly unresolvable issue a few months ago. We build (or at least tried to build) a properties file into the ear's "resource" directory. In the Ant world this worked fine for them, but when we moved to Maven we could not figure out how to get the property file in the ear referenced in the war's manifest class-path (and still use the add classpath feature of the mwar plugin.)

Let us know what the change might look like and I'll run it by the various team members here to see what they think.

Thank you