for A and C i have...
<dependencies>
<dependency>
<artifactId>B</artifactId>
<groupId>my.company</groupId>
<version>[1,2-!)</version>
</dependency>
</depedencies>
if I release B such that I create an incompatible release then release B as
2.X
we don't use modules, or pom inheritance for dependency management...
and it works very well...
On Fri, 22 Feb 2008 02:38:30 EJ Ciramella wrote:
> No no - if module A and module C depend on module B (which is developed
> by your company), how do you NOT put different versions in module A and
> C?
>
> We've done things like created a property in the pom that's the parent
> (the top most) of all the projects and in the sub projects, they all
> reference this property via the ${some.version.name} type convention.
> But, shortly, all these modules will be in their own branch and the
> concept of a "parent" pom (the one to rule them all) will go away and
> we'll lose this ability.
>
> What we've talked about doing is module A and module C will have the
> property and all their sub projects will reference that property via the
> ${foo.property} convention as described above. THEN - we'll have a pom
> that has dependencies on all these various modules poms (they'll have to
> be installed in our internal repository) and we can run the dependency
> convergence/dependency:analyze plugins.
>
> -----Original Message-----
> From: Michael McCallum [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 20, 2008 10:01 PM
> To: Maven Users List
> Subject: Re: Shared modules and versioning
>
> 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]
