On Sun, Aug 4, 2019 at 8:37 AM Emilian Bold <[email protected]> wrote:
> > 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. > But it already isn't just the checkout, right? We don't pack some modules into the distro, and we generate LICENSE and NOTICE based on what is in the source zip (ASF requirement is that LICENSE and NOTICE must contain only what is needed for the given zip, nothing more, nothing less). (Frankly, recording the source hash in the source distro feels like a reasonable idea to me in any case - currently, if I see a source zip of NetBeans, the only clue I have about the contents is the filename; that feels very weak.) > I would like that `git checkout 11.1 && ant build build-nbms > generate-uc-catalog` to be identical with the official release. > Not clear on how having the git hash recorded in the source distro is against this goal. Having the hash recorded would IMO actually help with that goal - regardless of whether the sources are checked out from the git repo, or unzipped from the zip, the hash that would be used would be the same. If we commit some ID to the repository, then two builds from two different hashes in git may get the same build version - that sounds to be against the very nature of the build version. Jan > --emi > > On Sun, Aug 4, 2019 at 9:06 AM Jan Lahoda <[email protected]> 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 <[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 > > > > > > > > > > > > > > --------------------------------------------------------------------- > 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 > > > >
