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]