In our artifactory we have a snapshot repo defined to handle max 5 unique snapshots. We added -SNAPSHOT-.extension to the filename. SNAPSHOT gets also converted to timestamp. Build is done with gradle and artifact gets published with bamboo and artifactory plugin.
A file deployed to artifactory ...
inhouse-snapshots:com/example/project/subproject/trunk-SNAPSHOT/subproject-trunk-SNAPSHOT-79.amp
becomes ...
inhouse-snapshots:com/example/project/subproject/trunk-SNAPSHOT/subproject-trunk-20120321.154621-1-79.amp
This is fine and every build adds a new file with incremented build number, but the timestamp-number always stays 20120321.154621-1 so we have a file list like:
Anybody has a solution or suggestion for a another directory layout?
As you've correctly observed, the build number you've attach to the deployed file name is identified as a classifier; this is because Maven doesn't specify a build number with a non-unique snapshot.
Artifactory maintains the same combination of timestamp and build number for "batches" of artifacts and "bumps" the timestamp and build number when it detects a new "batch"; there are 2 ways in which Artifactory detects artifact "batches" for the purpose of converting non-unique to unique snapshots:
Artifacts are deployed in the exact order of: artifact (no classifier), POM, attached artifacts (with classifiers); The first ordinary artifact to be deployed after the a POM will create a new "batch"; hence providing a new timestamp and builder number.
Artifacts deployed with a matrix param of the key "build.timestamp" and a value of a millisecond-based epoch timestamp; Artifacts with same timestamp values will be associated under the same "batch".
You should either omit the build number from the deployed file and deploy it with a "build.timestamp" matrix param (to make Artifactory bump the "batch" on each new deployment) or deploy the files already with the unique snapshot.