I have artifactory with multiple snapshots versions such as artifact-0.1-20120831.103456-5
.
My project depends on specific snapshot version. If I tell SBT
Addition Apart from the unique version plugin, sbt also has the aether-deploy plugin (see below).
There is the unique version plugin which lets you resolve your artifacts like you want. Quote from the page:
How to point at it
"0.1.0" or "0.1.0-20120602-073010" you can always use the static version number. "0.1.0-+" selects the latest 0.1.0 snapshot. "latest.integration" selects the latest revision regardless of its status. "latest.milestone" selects the latest revision with either Milestone or Release status. "latest.release" selects the latest with the Release status.
But you also have to publish with this plugin, since the artifacts are published in a different manner regarding the version: In your example, the artifact won't be stored under 0.1-SNAPSHOT directory but under 0.1-20120831.103456-5
Addition There is also the aether-deploy plugin which uses Aether (Aether offers a standard way of interacting with Maven repositories). Problem is that this plugin currently works for deploying only (as the name of the plugin suggests). Maybe the author has plans to extend it so that it works for resolving as well (sounds like a useful feature to me). If you can't publish with the unique version plugin (e.g. if the snapshots are not owned by you), then you could ask that at the sbt forum.
So I can't offer a solution that works precisely as maven does for your use case, but hopefully it gives some useful info for you and others.
An ugly workaround would be to install the snapshot artefact in your own groupId (say smith.external) NOT as a SNAPSHOT, using install:instal-file and declare the desired version number instead of declaring the usage of snapshot.
As you don't expect the version to change, you can rely on this, until you get it to work with a provided stable version (and the regular groupId)
Not the best solution but you may try to use conflict managers provided by Ivy (see apache docs). For example, 'latest-revision' is used by default and 'latest-compatible' manager should disallow any dependency conflicts.
It doesn't look easy to set up though, someone on google sbt group posted the following rule:
def addConflictManager(org: String, name: String, conflictManager: String) =
ivyModule <<= (ivyModule, streams) map { (module, s) =>
module.withModule(s.log) { (ivy, desc, _) =>
import _root_.org.apache.ivy.{core, plugins}
import core.module.id.ModuleId
import plugins.matcher.PatternMatcher
desc.addConflictManager(
ModuleId.newInstance(org, name),
ivy.getSettings.getMatcher(PatternMatcher.EXACT),
ivy.getSettings.getConflictManager("latest-compatible"))
module
}
}