The version-numbers for our jars have to be longer them x.x.x. We would rather need x.x.x.x to integrate some old-fashioned self-made mechanism. This is, because we tag our software with x.x.x and as soon as we have a delivery to a customer one specific jar has to be build exactly at this point of time to fit to another backend, which communicates with our program. For that reason this one jar has the version 2.3.4.1, when generated and in next delivery of the same Version it is build and named 2.3.4.2. Now artifactory cannot handle this an doesn't save more than x.x.x.2 in some cases. So we thought of maybe edit the regular expression in the maven repository layout (see attached Screenshot) Because testing the path in the field below shows, that it cannot handle the version number. Of course for the rest of our jars still x.x.x has to work..

For Example here is the maven-metadata.xml

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>com.firm</groupId>
  <artifactId>someid</artifactId>
  <version>1.5.1</version>
  <versioning>
    <latest>1.5.1</latest>
    <release>1.5.1</release>
    <versions>
      <version>1.4.62</version>
    </versions>
    <lastUpdated>20120926073942</lastUpdated>
  </versioning>
</metadata>

The folder structure looks like:

someid

• 1.4.62
  • 1.4.62.1
  • 1.4.62.2
  • 1.4.62.3

If we deploy an new artifact version (1.4.62.1), the maven-metadata.xml contains the 1.4.62.1 version. But the artifactory overrides the version number (1.4.62.x) to (1.4.62) after an unspecified time. It seems that the artifactory only support major, minor and revision numbers, and deletes the buildnumber. Now we looking for a solution do disable this behavior. We use the JFrog Artifactory version 2.5.0 (rev. 13086).

Any ideas, maybe? Thanks in andvance