Re: Shared modules and versioning
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shared modules and versioning
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared modules and versioning
for A and C i have...
dependencies
dependency
artifactIdB/artifactId
groupIdmy.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]
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
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]
RE: Shared modules and versioning
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]
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]
RE: Shared modules and versioning
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]
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]
