I'm migrating our build process from
Ant 1.7.0 to Maven 2.0.6, and I've got a whole series of JARs that I've written POMs for, most of which reside inside one of two WARs, which in turn live inside a single EAR.
Some of the projects inside the two WARs share libraries, and so I don't want to have those libraries duplicated in the WAR WEB-INF/lib directories, but rather include them in the EAR and make a reference to them in the WAR manifest. Maven doesn't support this directly, but they do have a workaround as described here:
Creating Skinny WARs I don't like this solution, since it requires me to specify by name the libraries I want to exclude (using the warSourceExcludes parameter of the maven-war-plugin), which sort of breaks Maven's flexibility, no? Now I have to specify filenames that I'd rather have Maven construct based on my groupId-artifactId-version.
So I concocted an alternative solution. All my POMs for this particular project (JARs, WARs, EAR) inherit from one "master" POM (not the Super POM). I have a huge DependencyManagement section which specifies all the libraries any of the sub-projects would need, along with preferred versions.
When I run across a library that I need to be in the EAR and not in a WAR's WEB-INF/lib, I set it's scope to "provided" in the master POM. Then, in the Dependency section of the EAR, I override it to "compile." For example:
I still have to add the libraries to the manifest--no getting out of that--but then I don't have to specifically exclude them.
In this way, my WAR has no problem compiling, but still looks to the EAR for those joint dependencies.
My question: is this a bad way to do this? Am I hijacking the purpose of the "provided" scope and potentially introducing problems for myself down the road?
What do y'all think?