I was intending to ask the exact same question since this is quite a laborious task for us. Our project hierarchy is highly component based, and as such, a bug fix release in a shared low-level component can sometimes require ten to twenty releases of dependent projects.
The solutions I can see for this are: 1) Use dependency management. Problems: MNG-1577; essentially moves dependency information to top-level project, causing duplication across projects and room for error. 2) Up the version to the new point-release in a single component where the issue was relevant, then rely on MNG-612 to ultimately select the latest version. Problems: MNG-612 is far from being implemented. 3) Use version ranges. Problems: build irreproducibility. 4) Use version ranges, but add support to the release plugin to resolve ranges to hard versions at release time. Problems: can't think of any. 5) Add automated support for this process. Where would this end up - Archiva, release plugin, separate tool? I quite like the idea of (4), what do others think? Mark On 30/10/06, John Casey <[EMAIL PROTECTED]> wrote:
Unless your projects are released in lock-step, you probably want to update the dependency version manually. While this is labor intensive, it also guarantees that you know exactly what you're building. As you analyze and test against newer versions of the dependency, you can manage that small piece of dependency metadata manually without much difficulty. If you're releasing all of the projects as a single app with a single version, you might use dependencyManagement from an application-level parent POM. HTH, John On 10/30/06, Pin Ngee Koh <[EMAIL PROTECTED]> wrote: > > I have a jar, say X.jar, which is reference by numerous projects. > Developers are changing and releasing various versions of X.jar for > releases. > What is the best way to manage the POM files of projects which depends on > it. > > 1. Use version range? E.g [1.0,2.0) > This option has potential of picking up unintended latest release of > X.jar > 2. Manually update reach project's POM file and up a minor version? > This option is labor intensive and difficult to manage. Also, > increasing a minor version in projects seems wrong and weird. > > What's a better way you would suggest? > > --------------------------------------------------------------------- > 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]
