Perhaps the original question is wrongly put, IMHO? If you have a shared library it should only be included ONCE in the end product, right? And this inclusion should be of a specific version (to allow build re-production), right? So all users of the shared library should list it as "provided" and the dependency will say which version was used for that particular build (re-production, once again). The end product will have a single "runtime" dependency of the shared library with the actual version to be included/used/provided.
PROBLEM: Maven does not automatically dected version mis-matches with "provided" dependencies. I do not end up with a working solution, but re-stated the issue arrives at a different core problem (one I have recently posted on this very mailing list). /jonas -----Ursprungligt meddelande----- Från: Mark Hobson [mailto:[EMAIL PROTECTED] Skickat: den 31 oktober 2006 10:54 Till: Maven Users List Ämne: Re: Managing Release Jars 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] **************************************************************************** This e-mail has been scanned for viruses by http://www.virus112.se **************************************************************************** **************************************************************************** Detta e-mail har blivit undersökt av http://www.virus112.se **************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
