maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hobson" <>
Subject Re: Managing Release Jars
Date Tue, 31 Oct 2006 09:53:55 GMT
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?


On 30/10/06, John Casey <> 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 <> 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:
> > For additional commands, e-mail:
> >
> >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message