> For Apache releases, we could print the git hash into a file in the source distro, and read it from that file. Having the source hash in the source distro might be a good idea anyway.
But then a release ZIP won't just be just a checkout of a commit ID but a generated ZIP file with other stuff in it. I would like that `git checkout 11.1 && ant build build-nbms generate-uc-catalog` to be identical with the official release. --emi On Sun, Aug 4, 2019 at 9:06 AM Jan Lahoda <lah...@gmail.com> wrote: > > Hi, > > Let me point out we have two manifest attributes: > OpenIDE-Module-Build-Version and OpenIDE-Module-Implementation-Version. The > Build-Version is the generated one, based on the date and git hash. If a > module specifies the impl. version, then both of these are generated, if > the module does not specify the impl. version, then > OpenIDE-Module-Implementation-Version is set to the build version, and > OpenIDE-Module-Build-Version is not generated. So, for reproducible builds, > we need to solve the OpenIDE-Module-Build-Version attribute. > > For implementation version, using the literal spec. version would be a nice > trick, but it is difficult to to me to accept that for the build version. > So, using git hash feels like a reasonable solution (and we already do that > for the build version, only prepend the current date!). For Apache > releases, we could print the git hash into a file in the source distro, and > read it from that file. Having the source hash in the source distro might > be a good idea anyway. > > Jan > > On Sun, Aug 4, 2019 at 6:33 AM Emilian Bold <emilian.b...@gmail.com> wrote: > > > 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 <niftin...@gmail.com> 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: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
