Using git hash assumes your are building a cloned repository. By definition this would not work on Apache releases which are just ZIP files of a given revision.
It might be simpler to just have a task that generates this stuff and actually commit it when doing releases (or perhaps, have a bot periodically commit it). --emi On Sat, Aug 3, 2019 at 10:06 PM Tim Boudreau <[email protected]> wrote: > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
