If I'm not mistaken the votes for using Maven plugins didn't have a single -1s, including a +1 from you Randim.
Writing Maven plugins is more complex that writing scripts, I don't dispute this. The main motivations for using Maven plugins is to keep things in the POM declarative and to hide (if necessary) different handlings for different platforms.
IMO, having a bunch of stand alone java programs that do this will have the same complexity than a Maven plugin, plus we'll lose all the benefits from Maven, version management, distribution/download via maven repo, declarative builds.
HADOOP-8887, it has been sitting around for a while, not because it is incomplete or complex but because we are not solving how the plugin gets into a Maven repo so it is available for the Hadoop build just to download it. I thinking we should have a discussion in common-dev@ on how to address this.
Going back to this particular JIRA, the other approach is to do it in the way Oozie does it:
For building a release tarball, there is a script 'mkdistro' which computes the SCM (SVN or GIT) info (uri, branch, commit), the build timestamp and passes it the Maven invocation as -D options, then they are avail as properties in the POM and the version-info.properties file gets filtered with those.
Essentially is this patch minus the plugin plus a script to call Maven.
The drawback of this approach is that the script has to do very much what saveVersion.sh does, meaning we are at square one.
We never tackled this in Oozie as a plugin because, so far, nobody as attempted to build/run Oozie server in Windows. I assume in Oozie we'd go the plugin way when such need arises.
I'm OK in updating this patch to do things how Oozie does it today, using bash. For how to do that in Windows command without using cygwin, I don't know. Again, I think we are back to square one with this approach, we are just the script logic of saveVersion.sh around.