Setting uniqueVersion = false, causes artifacts with SNAPSHOT
versions to be published as the exact version, and not with a unique
timestamp-buildnumber.
So, you don't really use uniqueVersion instead of SNAPSHOT, you use
it with SNAPSHOT.
And uniqueVersion is set to true by default in Maven, which is why by
default when you publish SNAPSHOTS that it makes timestamp-
buildnumber artifacts in the remote repository.
I really don't see how using this helps with anything... 'cept maybe
reduce the number of artifacts in the repo, and maybe remove the need
for that ${version} properly... at the expense of users not being
able to use past snapshot artifacts when newer snaps break their
project.
--jason
On May 20, 2007, at 3:39 AM, Jacek Laskowski wrote:
Hi,
Just spot it today and thought I'd share it here for further
consideration.
Every time Geronimo is released we're bothered with releasing OpenEJB
3.0 so no SNAPSHOT is to be included in a milestone release. I came
across the uniqueVersion element of snapshotRepository [1] that could
make the process nicer. If we used uniqueVersion instead of SNAPSHOT
while deploying openejb to the remote repository Geronimo could rely
on them rather than SNAPSHOTs that seem unreliable and error-prone.
It's a trade-off - a mini-release - between SNAPSHOTs and full-blown
releases. If we think Geronimo should use a higher version after it's
been published to a remote repository, Geronimo would be upgraded,
else it'd hold the earlier semi-SNAPSHOT.
WDYT?
[1] http://maven.apache.org/ref/2.0.4/maven-model/
maven.html#class_snapshotRepository
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
