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 <mario.wi...@gmx.net> 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<mario.wi...@gmx.net> 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<mario.wi...@gmx.net>: >>>> >>>> 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 > >
