On Tue, Sep 9, 2008 at 11:25 PM, 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?
>
>
>
>
>
>
Here's how we do it.
We have a corporate pom that defines the things which apply to all projects.
In each project, we have an aggregator pom (artifactId *projectName*-pom) at
the root level which defines all the modules. A child module of that
aggregator is used as the parent for all modules in the project (artifactId
*projectName*-parent)
depending on how crazy we feel, we either use the corporate pom or *
projectName*-parent as the parent for *projectName*-pom.
in *projectName*-parent we have a dependencyManagement section that defines
all our dependencies. Versions from other projects are controlled using
properties to ensure that we use the same suite of release of the other
project... for example
<project>
...
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>blah</groupId>
<artifactId>blah-api</artifactId>
<version>${blah.version}</version>
</dependency>
<dependency>
<groupId>blah</groupId>
<artifactId>blah-core</artifactId>
<version>${blah.version}</version>
</dependency>
<dependency>
<groupId>blah</groupId>
<artifactId>blah-special</artifactId>
<version>${blah.version}</version>
</dependency>
...
</dependencies>
</dependencyManagement>
...
<properties>
<blah.version>1.0</blah.version>
</properties>
...
</project>
as far as I know, you can use the <excludes> inside a dependencyManagement
to force the excludes on projects just declaring the dependency... though we
have not had to do this yet.
And then finally, when it comes time to roll a release with the latest
version we use
mvn versions:update-properties
to sync up the latest versions (note that in 1.0-alpha-1 you must define a
set of linkItems for versions-maven-plugin to know what to update... in
1.0-alpha-2 it will be able to auto-associate properties with the first
dependency (in the pom) that specifies the property as a version...
providing that the property is defined in the pom.)
