module.version values for SNAPSHOT project versions don't respect MMT's version order requirements

[mindthegab]

From peter.mo...@alfresco.com on May 21, 2014 13:49:56

When constructing an AMP from a SNAPSHOT version of a project, the alfresco-maven-plugin replaces the -SNAPSHOT suffix with an auto-generated timestamp (since MMT doesn't support non-numeric version numbers - see https://issues.alfresco.com/jira/browse/ENH-1232 for more details on this bug in MMT). So for example, a project version of 1.1.0-SNAPSHOT might result in a module version of 1.1.0.1405201742 (or similar - the final version number component varies as its an auto-generated timestamp).

When the developer is preparing a non-snapshot build, they will remove the -SNAPSHOT suffix from the project version, and the alfresco-maven-plugin will no longer append a timestamp. So for example, a project version of 1.1.0 results in a module version of 1.1.0 (no change).

The problem comes about when that non-SNAPSHOT build is deployed to a server that already has the SNAPSHOT build installed. By default, MMT will block installation of an AMP that has a numerically lower version (reading left to right) version than the currently installed version.

Using the examples above, we can see that the SNAPSHOT build has a module version of 1.1.0.1405201742, but the released version (which is, in fact, newer) has a module version of 1.1.0, which MMT considers to be older (1.1.0 is numerically less than 1.1.0.1405201742, reading the digits left to right).

A solution must ensure that the numerical ordering requirement of the current shipping versions of MMT are met, across both SNAPSHOT and non-SNAPSHOT project versions.

Original issue: http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=184

[mindthegab]

From peter.mo...@alfresco.com on May 21, 2014 10:53:40

The leiningen AMP plugin faced exactly this issue, and resolved it by converting SNAPSHOT versions into "1 less" than the stated version (solution here: https://github.com/pmonks/lein-amp/blob/master/src/leiningen/amp/impl.clj#L53 ).

For example project version 1.1.0-SNAPSHOT becomes module version 1.0.999, which clearly preserves the numerical ordering MMT requires (1.0.999 < 1.1.0).

Note: this approach has a risk of collisions if a given module ends up with an actual released project / module version of 1.0.999. This is why base-one-thousand was chosen for the "1 less" calculation, and a higher base could be selected if the collision risk is perceived as being too high.

[mindthegab]

From colum...@gmail.com on June 10, 2014 05:44:30

Labels: Milestone-Release-sdk-2.0.0

[mindthegab]

From colum...@gmail.com on July 17, 2014 06:22:30

Issue 69 has been merged into this issue.

[mindthegab]

From colum...@gmail.com on July 17, 2014 06:31:13

Status: Accepted
Cc: colum...@gmail.com

[mindthegab]

Working with @covolution to progress on the original issue (https://issues.alfresco.com/jira/browse/ENH-1232) and not having to hack around in the SDK. Keep you posted.

[pmonks]

Looks like this bug is starting to come home to roost: https://issues.alfresco.com/jira/browse/ACE-5006 ...

[gravitonian]

Fixed