Hmmm - that seems like a lot of work/duplication. Why not set it in
some higher level pom as a property and then use ${} type syntax to
expand it at your lower poms? What if someone doesn't fix/change/update
one of the poms version entries?
-----Original Message-----
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 7:29 PM
To: Maven Users List
Subject: Re: Shared modules and versioning
all the poms... although I would not recommend using version ranges for
external libraries that you have no control over
i've worked around that by using dependency compositions
On Thu, 21 Feb 2008 12:03:53 EJ Ciramella wrote:
> How do you implement version ranges? I think that could get us a bit
> further along, but still - where do you store this range of versions?
> Which pom?
>
>
> -----Original Message-----
> From: Michael McCallum [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 20, 2008 5:19 PM
> To: Maven Users List
> Subject: Re: Shared modules and versioning
>
> by a process of review by the person responsible...
>
> however you could use version ranges and have a project that depends
on
> all
> your deployable units. With appropriate version ranges you will get
> overcontrained version exceptions when someone has made the
deployables
> inconsistent.
>
> On Thu, 21 Feb 2008 08:11:35 EJ Ciramella wrote:
> > So we have a module that is shared across multiple deployable units.
> > It's imperative that each deployable unit uses the SAME version of
>
> this
>
> > dependency.
> >
> > If these deployable units are in their OWN project structure, how do
>
> you
>
> > uniformly enforce they use the same version without letting each
> > deployable unit have it's very own dependency listing. We've tried
> > making the version a property in our current parent project, but
this
> > doesn't feel like it's the correct place to put them (we're slowly
> > becoming more and more modular - and realizing there's no true
parent
>
> to
>
> > all projects).
> >
> > How have people solved this in scenario?
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
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]
