Retarget-deploy generates extremely long names for snapshot artifacts

[PayBas]

The following code of the retarget-deploy mojo can cause problems on some filesystems. By injecting the entire name into the otherDeployBranchPattern artifacts, it can create very very long directories and file-names.

https://github.com/egineering-llc/gitflow-helper-maven-plugin/blob/master/src/main/java/com/e_gineering/maven/gitflowhelper/RetargetDeployMojo.java#L89-L91

    /**
     * Given a String version (which may be a final or -SNAPSHOT version) return a
     * version version string mangled to include a `+normalized-branch-name-SNAPSHOT format version.
     *
     * @param version The base version (ie, 1.0.2-SNAPSHOT)
     * @param branchName to be normalized
     * @return A mangled version string with the branchname and -SNAPSHOT.
     */
    private String getAsBranchSnapshotVersion(final String version, final String branchName) {
        return version.replace("-SNAPSHOT", "") + otherBranchVersionDelimiter + branchName.replaceAll("[^0-9A-Za-z-.]", "-") + "-SNAPSHOT";
    }

For my current project we already inject a unique revision number into the version numbers (based on git describe --tags) to handle this issue. Having the gitflow-helper-maven-plugin come along and alter them to inject yet (much) more characters is undesirable.

I would suggest that this getAsBranchSnapshotVersion() call should be enabled by default for otherDeployBranchPattern branches (but the branch-name truncated to say 40chars), but an additional option to disable this call altogether for users (like me) who use a different solution.
Perhaps "snapshotArtifactUniqueNaming" with default = true?

[bvarner]

Interesting that you should mention this. :-) (good timing)

This actually intersects well with what I've been working on with #105. That issue was pointing out that that version manipulation was happening 'at the wrong time' and 'in the wrong way'.

To resolve it, I've been working in a branch where the version manipulation is moved to an extension, rather than part of the RetargetDeployMojo.

While I didn't account (yet) for disabling that extension, it would make sense to do that. It would also make sense in the case of this ticket, to provide some other strategies for resolving the 'unique' part of the version string.
If you'd like to play around / help out on this, feel free to fork and make PRs against feature/other-branch-reversioning-extension. I'd welcome the assistance.
(I have not finished updating the test cases yet...)

[bvarner]

You could also give it a try that way, so we know if it works IRL before a release. :-)

[PayBas]

Sorry for the late reply. I'll have a look :)

To be clear. We use git describe for our unique versioning because that way it's easier to see exactly which commit the deployed/tested artifact refers to.

[PayBas]

Didn't have time to do a thorough test yet unfortunately, and going on holiday for couple of weeks. Will check back in when I'm back.