> It might solve that problem, it doesn't solve this problem! We're trying to > get to a situation where different builds of the same source get the same > implementation versions. >
For *that* problem, your best bet is to switch from build numbers to using Git metadata. I do something similar for Maven libraries: https://github.com/timboudreau/mastfrog-parent/tree/master/revision-info-plugin Here is the code that does the heavy lifting: https://github.com/timboudreau/mastfrog-parent/blob/master/revision-info-plugin/src/main/java/com/mastfrog/maven/plugins/revisioninfo/LibInfo.java (in this case it is saving a properties file in META-INF, but easy enough to write the same info to a manifest) The main issues are: - You have to assume a local git binary exists, and have some heuristic for finding it (if you do this, please don't forget /opt/local/bin for those of us that build NetBeans in Jenkins on SmartOS!) - You have to assume the local git binary may be old, and not support some of the newer date flags to git log - Git's idea of an ISO timestamp is not quite an ISO date as Instant.parse() understands it (but you only need the hash here, so this probably doesn't matter) - If the repository is not clean (no modified sources since the last commit or pull), the best you can do is append "-dirty" to the version name and hope things work - It might be a good idea to blacklist from update servers any module with "-dirty" in its implementation version, to ensure users can actually get the bits as compiled That gets you out of date-stamp land with something that is a more dependable indicator of source-state - the git revision hash. I would strongly suggest *only* doing that for modules that *do not* specify an explicit implementation version, but it would certainly be better than a build number. That way, nothing that is already specifying an implementation version breaks. Or if you want to be even more conservative, leave the old build-number behavior on by default, and use some switch to turn git hashes on for newly created modules, then judiciously go through the sources and turn that switch on for existing modules and make sure nothing breaks. I once played with writing a Java API signature hash generator that used javac's API to mow through source code, and did some tricks with mapping source elements and character sequences to prime numbers to create a hash that only included public method signatures. Something like that would probably be a more ideal solution (unless someone writes their API in, say, Groovy - though if it processed .class files instead of sources, that would solve that). But git hash is pretty good. -Tim
