While there were three very enlightening suggestions to this question, nothing truly suits our needs.
1 - Using the version update thing requires the poms to be read/write, and do we rely on an automated process to simply update things and hope they build? Someone should be deciding on the version instead of having our integration server rifle through versions and updating them. Even if a user is manually running this, are they running it for all deployable apps that have a dependency on a "utils" type lib? Then they're on the hook for testing them all (even if their change to utils impacts only one of the deployable app). This solution seems like a lot of rope to hang yourself with. 2 - Wendy suggests using "lib list" type poms that combine typical shared libraries. So we have a "common api" lib and a "utils lib" - not always are they changed in unison and not always are they both needed for a deployable app. Putting a dependency on a lib list type pom that contains both the common api and the utils jar that would now pull both into a deployable app when it only needs utils seems wrong. In this example, I'm talking about two, there could be 20+ in this case. 3 - Stephen C's example was both confusing and utilizing the version update bit. See #1. Additionally, no one has answered why there isn't an <include> in the dependency stanza. This would go a LONG way to help minimize where one has to define redundant dependencies and their versions. Is this on a roadmap somewhere? Why not have <include> everywhere you have <exclude>? Wendy, you hinted at why, can you elaborate? -----Original Message----- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 2:43 AM To: Maven Users List Subject: Re: <dependency> has excludes - why not includes? I use properties to define the version and then use mvn versions:update-properties to sync Sent from my iPod On 9 Sep 2008, at 23:25, "EJ Ciramella" <[EMAIL PROTECTED]> wrote: > 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? > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
