RE: What is your strategy to manage dependencies?
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:mario.wi...@gmx.net] 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:mich...@redengine.co.nz] > 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: >>>> 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 d
RE: What is your strategy to manage dependencies?
It means my builds are reproducible. I tend to agree with you but it is a core requirement of SCM and imo, an indicator of doing things correctly, even if I have never really needed it ;-) Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -Original Message- From: Michael McCallum [mailto:mich...@redengine.co.nz] Sent: Wednesday, September 29, 2010 8:56 PM To: Maven Users List Subject: Re: What is your strategy to manage dependencies? What does it really mean to reproduce your build? The only time you really need to reproduce it is when something is broken and then what you REALLY need is a simple mechanism for making a new determinable release. On Thursday 30 September 2010 02:27:32 Yanko, Curtis wrote: > I don't advocate version ranges at all since your build may not be > re-produceable if you do. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: What is your strategy to manage dependencies?
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:mario.wi...@gmx.net] 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:mich...@redengine.co.nz] > 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: >>>> 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 >>>
Re: What is your strategy to manage dependencies?
In this situation I would simply not allow A to depend on C-1.0.0. I'd upgrade to C-2.0.0 for all modules and deal with whatever change A had to swallow to sustain that. Less surprises, problems found earlier. I haven't encountered a situation where it would be beneficial to do otherwise yet. Using dependencyManagement in a parent pom is just following DRY. I'm not saying version ranges can't be a useful way of working, I'd just prefer to be sure of what was being delivered. We do have a huge battery of automated acceptance tests running under CI so we can afford to upgrade drop in replacements often with low risk. Cheers Brian On 30 September 2010 00:07, Mario Wirth wrote: > 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:mich...@redengine.co.nz] >> 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: >>> >
Re: What is your strategy to manage dependencies?
Yes - it's a multi module project. It has several levels in fact and delivers two web apps and three izpack installed core java/swing apps. We do sometimes release modules internally with no change but a new version number. It doesn't actually cause us any problems and the consistency is worth the extra bandwidth. Our external release cycle is much longer so our real end users always get a set of applications that have a significant set of changes in them with accompanying release notes generated from svn log + jira. The huge benefit for us was the reduction in time to administrate third party library versions. Cheers Brian On 29 September 2010 23:59, Mario Wirth wrote: > Hi Brian, > is your project configuration a multi module project? If so, I guess this > is a nice solution. If you release all your modules at the same time, you > will never have dependency conflicts. Disadvantage of that approach is, that > you sometimes release moduls without a change. Am I right? > > Mario > > Am 29.09.2010 00:42, schrieb Brian Smith: > > Hi Mario >> >> Unless I'm misunderstanding - I do 2) for dependencies of external >> libraries >> plus 4) for dependencies on my own modules. >> >> I only specify versions of external dependencies in dependencyManagement >> in >> the parent, and do so with properties so they're convenient to change. >> >> Child poms just inherit versions from the parent dependencyManagement. >> >> I keep the versions of my own modules as SNAPSHOT of the next version, >> until >> release time and then release them all with the same version. >> >> Then set the versions to SNAPSHOT for the next (likely) version. >> >> This way I only maintain dependency versions in one place and everything >> that is released is consistent. >> >> I haven't needed version ranges or found diffcult conflicts despite >> depending on dozens of your fairly common java libraries. >> >> Hope that helps >> >> Brian >> >> >> On 28 September 2010 22:29, 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: 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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges > ) > > 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 pract
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:mich...@redengine.co.nz] 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: 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 re
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:mich...@redengine.co.nz] 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: 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org 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 dissemi
Re: What is your strategy to manage dependencies?
Hi Brian, is your project configuration a multi module project? If so, I guess this is a nice solution. If you release all your modules at the same time, you will never have dependency conflicts. Disadvantage of that approach is, that you sometimes release moduls without a change. Am I right? Mario Am 29.09.2010 00:42, schrieb Brian Smith: Hi Mario Unless I'm misunderstanding - I do 2) for dependencies of external libraries plus 4) for dependencies on my own modules. I only specify versions of external dependencies in dependencyManagement in the parent, and do so with properties so they're convenient to change. Child poms just inherit versions from the parent dependencyManagement. I keep the versions of my own modules as SNAPSHOT of the next version, until release time and then release them all with the same version. Then set the versions to SNAPSHOT for the next (likely) version. This way I only maintain dependency versions in one place and everything that is released is consistent. I haven't needed version ranges or found diffcult conflicts despite depending on dozens of your fairly common java libraries. Hope that helps Brian On 28 September 2010 22:29, 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: 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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges ) 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: What is your strategy to manage dependencies?
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:mich...@redengine.co.nz] 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: > >> 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 > >> yo
RE: What is your strategy to manage dependencies?
This article completely changed the way we structure our POMs http://olex.openlogic.com/wazi/2010/creating-intelligent-projects-with-m aven/ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -Original Message- From: Michael McCallum [mailto:mich...@redengine.co.nz] 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: > >> 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: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.ap
RE: What is your strategy to manage dependencies?
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:mich...@redengine.co.nz] 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: > >> 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: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr
Re: What is your strategy to manage dependencies?
Hi Mario Unless I'm misunderstanding - I do 2) for dependencies of external libraries plus 4) for dependencies on my own modules. I only specify versions of external dependencies in dependencyManagement in the parent, and do so with properties so they're convenient to change. Child poms just inherit versions from the parent dependencyManagement. I keep the versions of my own modules as SNAPSHOT of the next version, until release time and then release them all with the same version. Then set the versions to SNAPSHOT for the next (likely) version. This way I only maintain dependency versions in one place and everything that is released is consistent. I haven't needed version ranges or found diffcult conflicts despite depending on dozens of your fairly common java libraries. Hope that helps Brian On 28 September 2010 22:29, 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: >> >>> 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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges >>> ) >>> >>> 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: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: What is your strategy to manage dependencies?
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: 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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges) 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What is your strategy to manage dependencies?
5. Use released versions if possible and resolve conflicts one by one. Antonio 2010/9/24 Mario Wirth : > 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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges) > > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
What is your strategy to manage dependencies?
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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges) 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
