Temurin-build: В выпуске файла пуста Исходная строка: SOURCE = ""

Созданный на 13 февр. 2019  ·  8Комментарии  ·  Источник: adoptium/temurin-build

Платформа:

Любой

Архитектура:

Любой

Если я посмотрю на файл выпуска в 11.0.2 от 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=""

и за то же от 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"

Я вижу, что версия Oracle имеет исходный код SHA. Если вы используете бинарные файлы buildign, то источник должен быть идентифицируемым.

Все 8 Комментарий

Меня также интересует эта информация для однозначного определения сборки (с использованием SHA репозиториев, используемых для создания двоичного файла), чтобы связать результаты теста с конкретным двоичным файлом.

Привет, я только что загрузил и запустил 11.0.4 + 11, и в файле выпуска теперь есть git sha :-)

Исходное дерево для этого sha - https://github.com/AdoptOpenJDK/openjdk-jdk11u/tree/381c817fa41d549420b1f3a173d9147aa7a679cd

Есть ли способ увидеть связь между этим и источником на openjdk.java.net?

Тег 6a4d57474e1c971cccf4165b3d9d023928510010 находится в 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"

Вы можете сравнить с тегом 11.0.4 + 11 в mercurial (который будет иметь хэш фиксации) - у нас еще нет прямого сопоставления (поскольку наш источник git технически отклоняется)

Меня также интересует эта информация для однозначного определения сборки (с использованием SHA репозиториев, используемых для создания двоичного файла), чтобы связать результаты теста с конкретным двоичным файлом.

@smlambert Что касается этого, недавно появился https://github.com/AdoptOpenJDK/openjdk-build/pull/1949 , который добавляет либо хэш git, либо тег git в поле scmref в наших метаданных . Это то, что вы ищете?

Что касается исходной проблемы, мы уже давно перешли на 11.0.2 (сейчас мы на 11.0.7), можно ли ее закрыть, поскольку у новых двоичных файлов есть исходный хэш?

Отлично, поэтому, если я правильно понимаю, содержимым SOURCE должен быть SHA зеркал AdoptOpenJDK git (https://github.com/AdoptOpenJDK/openjdk-jdk11u и т. Д.) Для точки доступа, теперь он присутствует во всех версиях? 8 и 11+? для всех impls (хотя технически я могу просто посмотреть на вывод java -version для SHA для openj9, возможность использовать один и тот же подход для запросов для обоих - это хорошо).

Посмотрев на две недавние ночные публикации для 11 , я могу подтвердить, что JDK8 не содержит исходного значения (однако JDK11 содержит). 8 также содержит заметно меньше данных:

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"

хорошо, я думаю, для jdk8 история может быть немного сложнее ... было бы неплохо иметь ее и для этой версии LTS, но это нормально сделать это в рамках другой проблемы, если вы хотите закрыть эту, которая изначально просил для jdk11

Закрытие этого и отслеживание JDK8 в https://github.com/AdoptOpenJDK/openjdk-build/issues/1966

Была ли эта страница полезной?
0 / 5 - 0 рейтинги