I had assumed the version of the POM itself was a given. Developers don't ask, they manage the POM's themselves. So versioning the Parent is the one time we have to touch all of the POMs.
________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -----Original Message----- From: Mario Wirth [mailto:[email protected]] Sent: Wednesday, September 29, 2010 7:01 PM To: Maven Users List Subject: Re: What is your strategy to manage dependencies? Curtis, can you please explain what you do, if a developer asks for a new version of a dependency? Will you than update the dependency management section of the parent pom and create a release of the parent pom? If you don't do a release, you will overwrite the parent pom and lose your old dependency configuration. As a consequence you are not able to repeat a former build of the project. Mario Am 29.09.2010 15:11, schrieb Yanko, Curtis: > We use an idiom whereby we don't declare any version in the dependency > itself but use the depMgmnt section in a project level POM to *pin* > versions. > > > ________________________________ > > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT > Making IT Happen, one build at a time > > -----Original Message----- > From: Michael McCallum [mailto:[email protected]] > Sent: Tuesday, September 28, 2010 5:51 PM > To: Maven Users List > Subject: Re: What is your strategy to manage dependencies? > > I highly recommend using version ranges, in fact i wonder how people > work without them, it must be really hard to keep track of all the > dependencies. > > On Wednesday 29 September 2010 10:29:36 Mario Wirth wrote: >> Thank you Antonio, >> for your response. But is this really the only solution? Is there no >> plugin or technique available which helps to avoid (binary) >> compatibility conflicts between artifacts? >> Can anyone recommend the use of version ranges? >> >> Thanks, >> Mario >> >> Am 24.09.2010 09:47, schrieb Antonio Petrelli: >>> 5. Use released versions if possible and resolve conflicts one by > one. >>> >>> Antonio >>> >>> 2010/9/24 Mario Wirth<[email protected]>: >>>> Hi community, >>>> >>>> I am interested in your strategy, how to use Maven to make sure, >>>> all artifacts are selected in the right version. >>>> >>>> By default, if you add a dependency with it's version, that is only > a wish. >>>> Maven is allowed to change the artifact to a newer or an older >>>> version. It depends on the dependency tree and the distance to the > root. (see: >>>> http://www.sonatype.com/books/mvnref-book/reference/pom-relationshi >>>> ps-sect-project-dependencies.html#pom-relationships-sect-version-ra >>>> nges) >>>> >>>> As a consequence, sometimes my war file contains libs which do not >>>> fit together. The following solutions I've figured out so far: >>>> 1.Declare all needed dependencies in the pom of the war file. > Disadvantage: >>>> I have to do the work manually. >>>> 2.Use Dependency Management. In my parent pom I can declare all >>>> dependencies and their versions. Advantage: I have full control of >>>> the dependencies in the child moduls. Disadvantage: If I need to >>>> change a version of a particular dependency, I need to release a >>>> new version of the parent pom and afterwards I have to update the >>>> version number in all child projects which need the new version of > the dependency. >>>> 3.Use Version Ranges. Advantage: With version ranges I can add more > >>>> specific informations for Maven. This is used to support the >>>> conflict resolution and maven only selects artifacts which satisfy > all version ranges. Advantage: >>>> conflict resolution does not cause (binary) incompatibilty between >>>> the artifacts, if the version ranges are set correct. Disadvantage: > >>>> There is more effort during the release process: you need to build >>>> a release pom with resolved version ranges to make the build >>>> repeatable. You have to hide Snapshots during the release process, >>>> if you use boundaries like [4.0,). And finally, maven needs >>>> additional meta data from the repository. If the meta data are not > up to date, strange behaviour can happen. >>>> 4.Use only snapshots. If I use only snapshot versions, the latest >>>> version is always used. Disadvantage: Developing against snapshots >>>> can be frustrating because of the nature of snapshots ;-) But you >>>> will find out very fast, if something is binary incompatible. >>>> >>>> So, I am very interested in the best practise! How do you solve the > >>>> problem to manage all dependencies in their correct version. Thank >>>> you for your suggestions in advance. >>>> >>>> Mario >>>> >>>> ------------------------------------------------------------------- >>>> -- 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] >>> >> >> >> --------------------------------------------------------------------- >> 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] > > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity > to which it is addressed. If the reader of this e-mail is not the > intended recipient or his or her authorized agent, the reader is > hereby notified that any dissemination, distribution or copying of > this e-mail is prohibited. If you have received this e-mail in error, > please notify the sender by replying to this message and delete this e-mail immediately. > > > --------------------------------------------------------------------- > 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] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
