Updating the parent pom version I child pom is a trivial task and a small price to pay to have a well defined POM structure.
________________________________ 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:08 PM To: Maven Users List Subject: Re: What is your strategy to manage dependencies? Sorry, for the misleading post. I declare all dependencies, which are needed for compile in the project's pom (not parent pom). I trust on maven's conflict resolution and don't use Dependency Management at all at the moment. The reason for that I have described already: I don't want to release the parent pom and update the new version number in each child. If I don't do that, former builds are not repeatable. But if you trust maven's conflict resolution, it can lead to the following situation: There are 3 projects and their releationship: A-1.0.0 → B-1.0.0 → C-2.0.0 In addition A as the following dependency: A-1.0.0 → C-1.0.0 If project A is a war, it's lib folder will include B-1.0.0 and C-1.0.0. But B-1.0.0 needs classes which are only available in C-2.0.0. Consequence: You will get an exception at runtime. With version ranges you can avoid that. You have to write in the POM of B → C[2.0.0, 2.1). Maven will consider this additional information and select version C-2.0.0. But version ranges lead to other problems. You need correct meta-data and you have to create a release pom to resolve the version ranges at release time. (see: http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html) I really would like to use version ranges, but I read very often in this forum: Avoid version ranges! (the post of Michael McCallum is an exception ;-) ) I am not sure if it's the maven way. On the other hand: If you do the dependency management manually, you use Maven just to download the artifacts. Is that the maven way? Thanks, Mario Am 29.09.2010 15:27, schrieb Yanko, Curtis: > > I do find it surprising that your saying declaring a dependency is > *only a wish*? A declared dependency *should be* closest to the root, > our do you make your declarations in a Parent POM? > > We too used to *factor up* any shared dep to the Parent but have > stopped since it creates a couple of issues, yours being just one of them. > >> 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. > > If you are declaring versions in depMgmnt, don't put a version in the > project pom dependency. Work with a SNAPSHOT POM version until you > have what you want, then RELEASE it, to nail it down. > > I don't advocate version ranges at all since your build may not be > re-produceable if you do. > > ________________________________ > > 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]
