[jira] [Comment Edited] (LUCENE-9301) Gradle: Jar MANIFEST incomplete

["Uwe Schindler (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117599#comment-17117599 ] 

Uwe Schindler edited comment on LUCENE-9301 at 5/27/20, 10:02 AM:
------------------------------------------------------------------

I would nuke the datestamp from the manifest. The version and gitrev don't change while developing only when you commit (and then it's fine to change it).

But the date/time should not be part of the Manifest, unless it's part of a separate Manifest entry that can be excluded from changes checks by Gradle. IMHO, the whole discussion goes into the direction: The date/time is already in file metadata of each jar entry, why repeat it? Gradle knows how to handle that as it ignores the file dates.

Another thing to look into: With timestamps, builds are not reproducible. They aren't also without our Manifest changes (JAR is always different because of ZIP entry dates), but other projects already started to set a fixed date for the ZIP file entries to make builds reproducible. Also the JAR task should sort the files in consistent order - OpenJDK is working on that, but custom tools like Gradle may build JAR files by their own code.


was (Author: thetaphi):
I would nuke the datestamp from the manifest. The version and gitrev don't change while developing only when you commit (and then it's fine to change it).

But the date/time should not be part of the Manifest, unless it's part of a separate Manifest entry that can be excluded from changes checks by Gradle. IMHO, the whole discussion goes into the direction. The date/time is already in file metadata of each jar entry, why repeat it? Gradle knows how to handle that as it ignores the file dates.

Another thing to look into: With timestamps, builds are not reproducible. They aren't (JAR is always different because of ZIP entry dates), but other projects already set a fixed date for the ZIP file entries to make builds reproducible. Also the JAR task should sort the files in consistent order - OpenJDK is working on that, but custom tools like Gradle may build JAR files by their own code.

> Gradle: Jar MANIFEST incomplete
> -------------------------------
>
>                 Key: LUCENE-9301
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9301
>             Project: Lucene - Core
>          Issue Type: Sub-task
>          Components: general/build
>    Affects Versions: master (9.0)
>            Reporter: Jan Høydahl
>            Assignee: Dawid Weiss
>            Priority: Major
>             Fix For: master (9.0)
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> After building with gradle, the MANIFEST.MF file for e.g. solr-core.jar containst
> {noformat}
> Manifest-Version: 1.0
> {noformat}
> While when building with ant, it says
> {noformat}
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.10.7
> Created-By: 11.0.6+10 (AdoptOpenJDK)
> Extension-Name: org.apache.solr
> Specification-Title: Apache Solr Search Server: solr-core
> Specification-Version: 9.0.0
> Specification-Vendor: The Apache Software Foundation
> Implementation-Title: org.apache.solr
> Implementation-Version: 9.0.0-SNAPSHOT 9b5542ad55da601e0bdfda96bad8c2c
>  cabbbc397 - janhoy - 2020-04-01 16:24:09
> Implementation-Vendor: The Apache Software Foundation
> X-Compile-Source-JDK: 11
> X-Compile-Target-JDK: 11
> {noformat}
> In addition, with ant, the META-INF folder also contains LICENSE.txt and NOTICE.txt files.
> There is a macro {{build-manifest}} in common-build.xml that seems to build the manifest.
> The effect of this is e.g. that spec an implementation versions do not show in Solr Admin UI



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org