I think scope>import</scope is what you are looking for, but IMHO it might be less than perfectly defined in the docs (last time I looked)
On 24 August 2010 22:54, Zac Thompson <[email protected]> wrote: > I've racked my brain to come up with an ideal solution to this, > without success, so I'm throwing myself on the mercy of the group. > Any and all advice is greatly appreciated. > > I have a project with many modules that are all released together; > let's say they're in group ca.zac.A. The parent pom (also the > aggregator) for the group defines dependencyManagement for all the > child poms so that keeping versions consistent within the group and > releasing them together is easy. So far, so good. > > But other projects might depend on a subset of the group, or have > transitive dependencies on them, so I list the whole set of ca.zac.A > modules in the dependencyManagement section of each such project: I > want to be sure of keeping the versions consistent and known, and > sometimes Maven's resolution ends up choosing mixed versions. But > adding the whole set means I end up duplicating a large block of the > POM in multiple projects. And if I add a new module that might get > transitively included, then I have to update multiple places. I am > looking for a way to centralize this information. > > 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using > properties to affect transitive dependencies is not likely to happen > any time soon, and I wholeheartedly agree that it's a bad idea anyway. > > 2) The idea of inheriting from the ca.zac.A parent pom worked with > maven 2.1.0, but not well for other versions (and it smells bad > anyway). > > 3) I *could* list them all in dependencyManagement in my > "organizational parent" pom, with the version controlled by a single > property, but then I'd have to update it whenever a new module is > added to ca.zac.A. Having such a pom list a sizable set of my > projects is probably workable, but it feels like I'm abusing it. > > 4) Multiple inheritance is not supported nor desired, and I understand > that the planned "mixin" capability won't be around until post-3.0. I > could have an intermediate parent pom, with just the > dependencyManagement entries for my group, but in fact, I have more > than one such set. So I'd have to put all such groups in one pom, and > update it whenever ca.zac.A or .B or .C have a new module. This is > probably my best option, but it still feels less than ideal: I'd > rather be able to update a discrete place for each group. In > practical terms, this isn't much different than putting it in the org > parent, because I'd have to use this as the parent for most projects > anyway. > > Am I stuck for now? Is there some other option I'm just not seeing? > > What I find myself wishing for is something like the following, and > just have it apply to all the artifacts in the group (note that I > would only ever want to do it for a groupId that I controlled): > > <dependencyManagement> > <dependencies> > <dependency> > <groupId>ca.zac.A</groupId> > <versionId>${ca.zac.A.version}</versionId> > <!-- note no artifactId is listed --> > </dependency>... > > Then in the child POMs I could just specify the ca.zac.A.version > property. Is there a reason why something like this is a bad idea and > would never happen? Or should I just go ahead and submit a request > for it? It looks like there used to be a similar one at MNG-3633 > (using wildcards), but that JIRA has vanished! > > Should I just grin and bear it until mixins in 3.1? If so, I'll see > if there's some way I can contribute. > > Zac > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
