Warpath transitive depencies [warpath -> warpath -> warpath] problem

It is not possible to define the order in which warpath dependencies will be processed for a given project, which can cause issues when there are warpath transitive dependencies, as described below.

Project A is a war project, currently in version 1.2

• in my case, A is a sort of base "abstract web module", which contain some general purpose Struts Actions, decorators, stylesheets, images etc.

Projects B, C, ..., N are war projects, which currently depend on version 1.1 of A -> both war and warpath dependencies

• as these projects have warpath dependencies on A, it results in having all the classpath elements of A into their /WEB-INF/classes

Project Z is a war project that depends on A, B, and C

• i.e., Z is another web module that, will basically have all the Struts actions (and therefore eveything that comes with it - Services, DAO, Entities...) of all three projects. ----> but it depends on version 1.2 of A – i.e., I've added new features to A and want to have them in Z while they still are not available in B, C
• Z has a struts.xml file that includes every each one of struts-project-A.xml, struts-project-B.xml, and struts-project-C.xml. Also, its web.xml settings will include all applicationContext files from A, B, and C.

What happens is: when warpath dependencies (A/B/C) are being processed in Z, what roughly happens is: contents from /WEB-INF/classes from A, B, and C are being copied into /WEB-INF/classes of Z. But there is no guarantee regarding the order in which they will be copied. And it may happen that classpath resources of A v1.2 will be replaced by the ones of v1.1 because they are embedded in B and C war files.

If you look at how maven war plugin works, you will see that it is possible to define the overlay order. See http://maven.apache.org/plugins/maven-war-plugin/overlays.html. So I can avoid this from happening to the web content (jsp, decorators, css, etc). But this is not possible for the classpath dependencies.

From my point of view, there are two ways of solving this:
1) Allowing to define warpathExcludes and warpathIncludes in a per-dependency basis - this way I could explcitly exclude all the resources from A when declaring warpath depency on B and C (in Z's pom.xml)
2) Being able to define the order in which the warpath depencies are going to be processed. In this case, I could ensure that A will the last one, therefore overriding/adding any old stuff that came from B and C. - I think this is the best option