i use standard refactoring techniques to avoid duplication and ensure clean
dependency trees
On Thu, 21 Feb 2008 14:56:19 EJ Ciramella wrote:
> 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]
