We're still battling away with how best to set up a shared set of libs such that we can specify their version in a singular location and stumbled across the <type>pom</type> <scope>import</scope> bit.
This would be great as we could create a corporate "lib list" type pom and then all projects could list it as a dependency. The one shortcoming of this is, if there are libs listed inside this "lib list" pom, you'd get them any way. I see a set of excludes, but that could get really long (say there are 30 shared libs, but we're only interested in three). Is a matching "include" coming to match the "exclude" statement in the dependency bits? That would make life so much easier... The next approach to "shared libs across multiple deployable units" would be to use dependencyManagement, but this only works as long as you have a parent/child relationship. If you have an aggregator pom, dependencyManagement isn't passed along to any of the sub builds, so this doesn't help. And finally, you could have corporate pom -> parent pom -> child pom where dependencyManagement is set in the corporate pom, and versionless dependencies are set at the child pom level. The problem with this is you're updating the version of the corporate pom with each library change (unless you make it a snapshot version - forget about using the release plugin at this point). /deepbreath What do people think? What are people doing in scenarios where you have multiple deployable units that have dependencies on the same four or five internal libs (some that change VERY frequently)? Anyone wanna make a recommendation based on the three suggested approaches above?
