Ahhh, A plugin to fix version range problems, I'll have to ckeck this out.
-Dave On Wed, Apr 22, 2009 at 10:41 AM, Stephen Connolly < [email protected]> wrote: > 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] > > > > > > > > > > > > > >
