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.