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]
