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

["Dawid Weiss (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dawid Weiss reopened LUCENE-9301:
---------------------------------

D. Smiley expressed concerns that with the manifest including timestamps JARs are reassembled every time on rebuild (they should be because their inputs change).

I understand this may be a problem with frequent builds and there are workarounds that can be applied but cache avoidance or exclusion is not the right way. The current manifest contains these fields that may vary from build to build:
{code:java}
"${project.version} ${gitRev} - ${System.properties['user.name']} - ${buildDate} ${buildTime}" {code}
I'd say my preferred way of solving this would be to:

1) remove buildTime entirely or truncate it to, say, an hour. This makes full rebuilds of JARs trigger automatically every longer period of time and still leaves all the information. Git revision and build date should be sufficient. The time to re-assemble JARs is fairly small anyway.

2) make the implementationVersion line different for production and snapshot builds. Snapshot builds could only include project version so that jars remain fairly constant between rebuilds.

3) only add implementationVersion field to jars if we run together with a different task (something like top-level "release"). I don't like this because it adds cross-task dependencies and complexity that will make people scratch their heads.

> 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