Re: Shared modules and versioning

2008-02-21 Thread VUB Stefan Seidel
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

RE: Shared modules and versioning

2008-02-21 Thread EJ Ciramella
/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

Re: Shared modules and versioning

2008-02-21 Thread Michael McCallum
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

Shared modules and versioning

2008-02-20 Thread EJ Ciramella
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

Re: Shared modules and versioning

2008-02-20 Thread Michael McCallum
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

RE: Shared modules and versioning

2008-02-20 Thread EJ Ciramella
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

Re: Shared modules and versioning

2008-02-20 Thread Michael McCallum
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

RE: Shared modules and versioning

2008-02-20 Thread EJ Ciramella
[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

Re: Shared modules and versioning

2008-02-20 Thread Michael McCallum
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