You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by EJ Ciramella <ej...@upromise.com> on 2008/02/20 20:11:35 UTC
Shared modules and versioning
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?
Re: Shared modules and versioning
Posted by Michael McCallum <gh...@apache.org>.
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:gholam@apache.org]
> 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:gholam@apache.org]
> > 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:gholam@apache.org]
> > > 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Shared modules and versioning
Posted by EJ Ciramella <ej...@upromise.com>.
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:gholam@apache.org]
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:gholam@apache.org]
> 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:gholam@apache.org]
> > 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Shared modules and versioning
Posted by Michael McCallum <gh...@apache.org>.
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:gholam@apache.org]
> 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:gholam@apache.org]
> > 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Shared modules and versioning
Posted by EJ Ciramella <ej...@upromise.com>.
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:gholam@apache.org]
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:gholam@apache.org]
> 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Shared modules and versioning
Posted by Michael McCallum <gh...@apache.org>.
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:gholam@apache.org]
> 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Shared modules and versioning
Posted by EJ Ciramella <ej...@upromise.com>.
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:gholam@apache.org]
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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Shared modules and versioning
Posted by Michael McCallum <gh...@apache.org>.
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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Shared modules and versioning
Posted by VUB Stefan Seidel <ss...@vub.de>.
Create an extra artifact A of packing type pom.
Declare the dependency to the shared module M within A, with the version
you want/need.
In your projects P1, P2, ... declare a dependency on A (here, a version
range is useful, since A is your own project).
Thus, all projects P1...Px use the same version of M, namely the one you
declare in A. If you want to change to another version of M, change it
in A and deploy/release it.
regards,
Stefan
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?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org