Which is where using properties and the versions-maven-plugin comes to the
rescue....
<project>
...
<dependencies>
...
<dependency>
<groupId>com.foobar</groupId>
<artifactId>foobar-core</artifactId>
<version>${foobar-version}</version>
</dependency>
<dependency>
<groupId>com.foobar</groupId>
<artifactId>foobar-optional</artifactId>
<version>${foobar-version}</version>
</dependency>
...
</dependencies>
...
<properties>
<foobar-version>1.2</foobar-version>
</properties>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>1.0-alpha-3-SNAPSHOT</version>
<configuration>
<properties>
<property>
<name>foobar-version</name>
<version>[1.2,2.0-!)</version>
</property>
</properties>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
running
mvn versions:update-properties
will look for newer versions of both linked artifacts that are within the
specified range and update the property if required.
mvn versions:update-properties -DallowSnapshots=true
is the only way to get -SNAPSHOT versions...
Note: if your reactor contained a -SNAPSHOT version of both of the foobar
dependencies, then update-properties will detect this and assume that you
probably want to use the version from the reactor and not the previous
release... but there's a flag to turn that behaviour off.
-Stephen
2009/4/22 David Hoffer <[email protected]>
> Unfortunately version ranges have so many bugs i don't find them useful
> either. The problem with version ranges is that they will, in most cases,
> include snapshots although that's both not intended and violates the
> version
> range spec.
>
> -Dave
>
> On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
> [email protected]> wrote:
>
> > 2009/4/22 Michael Hüttermann <[email protected]>
> >
> > > Hello experts,
> > >
> > > how do you set up the process if you use RELEASE for a dependency in a
> > > POM, and work with VCS branches ?
> >
> >
> > you stop using RELEASE for a dependency.
> >
> > RELEASE corresponds to the last released version... so if you release, in
> > order
> >
> > 1.0.0
> > 1.0.1
> > 1.1.0
> > 1.1.1
> > 2.0.0
> > 1.0.2
> >
> > Then RELEASE will correspond to 1.0.2 as that was the last version
> > released.
> >
> > The solution is to use version ranges, i.e. work on the 1.0.x branch
> would
> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > 1.0.0
> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> that
> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> > than 1.1.0)
> >
> > Of course version ranges only work if you follow maven's rules for
> version
> > numbering... if you cannot follow maven's (some would say slightly
> strange)
> > version numbering scheme you will need to do some manual work... to help
> > automate the manual work, you'll probably end up using
> > versions-maven-plugin
> > and specifying the version using a property.
> >
> >
> > > What is your best practice? Probably a
> > > branch will have to adress another, older version of an artifact,
> > actually
> > > it has to adress a stable, tagged version. What happens if on HEAD you
> > use
> > > new versions of dependencies (so a new version for RELEASE), ... do you
> > > adjust all of your branches to remove the RELEASE token and enter a
> > > dedicated version? Isn't that a nightmare ?
> >
> >
> > I think you will realise from my earlier comment that there is *no way in
> > hell* that you would use RELEASE.
> >
> > FYI, the LATEST and RELEASE versions were initially more for use in
> > specifying plugin versions... but they are so problematic that everyone
> > pretty much avoids them
> >
> > -Stephen
> >
> > >
> > >
> > > Thanks !!
> > >
> > >
> > > Michael
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
> >
>
