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 <[email protected]> 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 <[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 > > > >
