Temurin-build: La version du fichier a une chaîne source vide : SOURCE=""

Créé le 13 févr. 2019  ·  8Commentaires  ·  Source: adoptium/temurin-build

Plate-forme:

Quelconque

Architecture:

Quelconque

Si je regarde le fichier de version dans 11.0.2 de AdoptOpenJDK

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=""

et pour la même chose d'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"

Je vois que la version Oracle a un code source SHA. Si vous construisez des binaires à partir de la source, alors la source doit être identifiable.

bug

Tous les 8 commentaires

Je suis également intéressé par cette information pour définir de manière unique une construction (avec les SHA des dépôts étant extraits pour créer le binaire) afin de relier les résultats des tests à un binaire particulier.

Salut, je viens de télécharger et d'exécuter 11.0.4+11 et le fichier de version contient maintenant un git sha :-)

L'arbre source de ce sha est https://github.com/AdoptOpenJDK/openjdk-jdk11u/tree/381c817fa41d549420b1f3a173d9147aa7a679cd

Existe-t-il un moyen de voir le lien entre cela et la source sur openjdk.java.net ?

La balise il y a 6a4d57474e1c971cccf4165b3d9d023928510010 et qui se produit dans openjdk-jdk11u/.hgtags

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"

Vous pouvez comparer avec la balise 11.0.4+11 dans mercurial (qui aura un hachage de validation) - nous n'avons pas encore de mappage direct (puisque notre source git s'écarte techniquement)

Je suis également intéressé par cette information pour définir de manière unique une construction (avec les SHA des dépôts étant extraits pour créer le binaire) afin de relier les résultats des tests à un binaire particulier.

@smlambert À ce sujet, https://github.com/AdoptOpenJDK/openjdk-build/pull/1949 a récemment ajouté un hachage git ou une balise git au champ scmref de nos métadonnées . C'est ça que tu cherches ?

En ce qui concerne le problème d'origine, nous avons depuis longtemps dépassé la version 11.0.2 (nous sommes maintenant sur la version 11.0.7), peut-il être fermé car les nouveaux binaires ont un hachage source ?

Super, donc si j'ai bien compris, le contenu de SOURCE devrait être le SHA des miroirs git AdoptOpenJDK (https://github.com/AdoptOpenJDK/openjdk-jdk11u, etc) pour hotspot, est-il maintenant présent pour toutes les versions ? 8 et 11+ ? pour tous les impls (bien que je puisse techniquement simplement regarder la sortie java -version pour les SHA pour openj9, pouvoir utiliser la même approche pour interroger les deux est bien).

En regardant deux nightlies récentes pour JDK8 et 11 , je peux confirmer que JDK8 ne contient pas de valeur source (JDK11 cependant). 8 contient également nettement moins de données :

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, je suppose que pour jdk8 l'histoire peut être un peu plus compliquée... ce sera bien de l'avoir pour cette version LTS aussi, mais c'est bien de le faire sous un autre numéro, si vous souhaitez fermer celui-ci, qui à l'origine l'a demandé pour jdk11

Cette page vous a été utile?
0 / 5 - 0 notes