Temurin-build: Dateifreigabe hat leere Quellzeichenfolge: SOURCE=""

Erstellt am 13. Feb. 2019  ·  8Kommentare  ·  Quelle: adoptium/temurin-build

Plattform:

Irgendein

Die Architektur:

Irgendein

Wenn ich mir die Release-Datei in 11.0.2 von AdoptOpenJDK anschaue

IMPLEMENTOR="AdoptOpenJDK"
IMPLEMENTOR_VERSION="AdoptOpenJDK"
JAVA_VERSION="11.0.2"
JAVA_VERSION_DATE="2019-01-15"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=""

und dafür von Oracle

IMPLEMENTOR="Oracle Corporation"
IMPLEMENTOR_VERSION="18.9"
JAVA_VERSION="11.0.2"
JAVA_VERSION_DATE="2019-01-15"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=".:144d476b6efe"

Ich sehe, dass die Oracle-Version einen Quellcode-SHA hat. Wenn Sie Binärdateien vom Quellcode erstellen, muss die Quelle identifizierbar sein.

bug

Alle 8 Kommentare

Ich interessiere mich auch für diese Informationen, um einen Build eindeutig zu definieren (wobei die SHAs von Repos eingezogen werden, um die Binärdatei zu erstellen), um Testergebnisse mit einer bestimmten Binärdatei zu verknüpfen.

Hi, ich habe gerade 11.0.4+11 heruntergeladen und ausgeführt und die Release-Datei enthält jetzt ein Git-Sha :-)

Der Quellbaum für dieses sha ist https://github.com/AdoptOpenJDK/openjdk-jdk11u/tree/381c817fa41d549420b1f3a173d9147aa7a679cd

Gibt es eine Möglichkeit, den Link zwischen diesem und der Quelle auf openjdk.java.net zu sehen?

Das Tag dort ist 6a4d57474e1c971cccf4165b3d9d023928510010 und kommt in openjdk-jdk11u/.hgtags vor

IMPLEMENTOR="AdoptOpenJDK" IMPLEMENTOR_VERSION="AdoptOpenJDK" JAVA_VERSION="11.0.4" JAVA_VERSION_DATE="2019-07-16" MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs" OS_ARCH="x86_64" OS_NAME="Windows" SOURCE=".:git:381c817fa41d"

Sie können mit dem 11.0.4+11-Tag in mercurial vergleichen (das einen Commit-Hash hat) - wir haben noch keine direkte Zuordnung (da unsere Git-Quelle technisch abweicht)

Ich interessiere mich auch für diese Informationen, um einen Build eindeutig zu definieren (wobei die SHAs von Repos eingezogen werden, um die Binärdatei zu erstellen), um Testergebnisse mit einer bestimmten Binärdatei zu verknüpfen.

@smlambert Diesbezüglich wurde kürzlich https://github.com/AdoptOpenJDK/openjdk-build/pull/1949 hinzugefügt , das entweder einen Git-Hash oder ein Git-Tag zum scmref Feld in unseren Metadaten hinzufügt. Ist es das, wonach Sie suchen?

Was die ursprüngliche Ausgabe angeht, wir sind längst über 11.0.2 hinausgekommen (wir sind jetzt bei 11.0.7), kann dies geschlossen werden, da die neuen Binärdateien einen Quell-Hash haben?

Großartig, wenn ich das richtig verstehe, sollte der Inhalt von SOURCE der SHA der AdoptOpenJDK-Git-Spiegel (https://github.com/AdoptOpenJDK/openjdk-jdk11u usw.) für Hotspot sein, ist er jetzt für alle Versionen vorhanden? 8 und 11+? für alle Impls (obwohl ich technisch nur die Ausgabe von java -version für SHAs für openj9 betrachten kann, ist es gut, denselben Ansatz für die Abfrage von beiden verwenden zu können).

Wenn ich mir zwei aktuelle Nachtblätter für 11 ansehe , kann ich bestätigen, dass JDK8 keinen Quellwert enthält (JDK11 jedoch). 8 enthält auch deutlich weniger Daten:

JAVA_VERSION="1.8.0_262"
OS_NAME="Darwin"
OS_VERSION="11.2"
OS_ARCH="x86_64"
SOURCE=""
IMPLEMENTOR="AdoptOpenJDK"
IMPLEMENTOR_VERSION="AdoptOpenJDK"
JAVA_VERSION="11.0.8"
JAVA_VERSION_DATE="2020-07-14"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Darwin"
SOURCE=".:git:824f8474f533"

ok, ich denke für jdk8 ist die Geschichte vielleicht etwas komplizierter... es wäre schön, es auch für diese LTS-Version zu haben, aber es ist in Ordnung, dies unter einem anderen Thema zu tun, wenn Sie dieses ursprünglich schließen möchten habe es für jdk11 angefordert

Schließen Sie dies und verfolgen Sie JDK8 in https://github.com/AdoptOpenJDK/openjdk-build/issues/1966

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

joeyleeeeeee97 picture joeyleeeeeee97  ·  5Kommentare

PierreZ picture PierreZ  ·  5Kommentare

karianna picture karianna  ·  7Kommentare

mstoodle picture mstoodle  ·  3Kommentare

sxa picture sxa  ·  3Kommentare