Add JVM Version, Vendor, and Build Source to Json Metadata #2077
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
austin0
added
the
enhancement
|
|
I definitely would like to see common/standard naming between the API and the release file (calling a vendor a vendor, a variant a variant, distribution a distribution, etc). So if there are tags/names that are different, for the sake of not confusing people later, we should align them. FYI @llxia This work relates to how we are trying to get SHAs for TRSS and test (for hotspot builds)... (adoptium/aqa-test-tools#317 and adoptium/aqa-tests#1949). Ideally I would love to see that information in the java -version output (like how openj9 does it) as then its easy to write tools that can query the JVM directly rather than find and echo out the contents of a release file, but presumably that is an upstream conversation to have. |
|
@aahlenst I've been reading through the api thread and adding EDIT: I'm leaving this out of this PR until more concrete plans are laid out. Adding major/minor/etc is a good idea and I'll get on it. Hotspot is a weird one; jdk8u has
Any issues with this? |
austin0
force-pushed
the
jsonAdditions
branch
2 times, most recently
from
b00eb1e
to
d858e31
Compare
austin0
force-pushed
the
jsonAdditions
branch
from
d858e31
to
b9b8c33
Compare
austin0
force-pushed
the
jsonAdditions
branch
from
b9b8c33
to
f6849f1
Compare
austin0
force-pushed
the
jsonAdditions
branch
from
f6849f1
to
315389f
Compare
🟢 PR TESTER RESULT 🟢✅ All pipelines passed! ✅ |
austin0
force-pushed
the
jsonAdditions
branch
from
315389f
to
fe0f2db
Compare
|
@aahlenst @johnoliver this is how the metadata file currently looks, any issues with it?
|
🟢 PR TESTER RESULT 🟢✅ All pipelines passed! ✅ |
|
I think |
|
If it's fine to only have it for OpenJ9 then I'll make those changes, the hotspot numbers were effectively filler anyway as I assumed there had to be a value to avoid breaking other things. The numbers come from the |
austin0
force-pushed
the
jsonAdditions
branch
from
fe0f2db
to
377e776
Compare
Signed-off-by: Austin Bailey <Austin.Bailey@ibm.com>
austin0
force-pushed
the
jsonAdditions
branch
from
377e776
to
ececea5
Compare
🟢 PR TESTER RESULT 🟢✅ All pipelines passed! ✅ |
|
@johnoliver Have changed the key to |
karianna
approved these changes
Sep 18, 2020
🟠 PR TESTER RESULT 🟠❎ Some pipelines failed or the job was aborted! ❎ |
🟠 PR TESTER RESULT 🟠❎ Some pipelines failed or the job was aborted! ❎ |
|
Only failure is jdk11u-windows-x64-hotspot and unrelated to this PR. @johnoliver |
austin0
force-pushed
the
jsonAdditions
branch
from
a5b1c89
to
4dc4c29
Compare
Signed-off-by: Austin Bailey <Austin.Bailey@ibm.com>
austin0
force-pushed
the
jsonAdditions
branch
from
4dc4c29
to
0068bb3
Compare
🟢 PR TESTER RESULT 🟢✅ All pipelines passed! ✅ |
AdamBrousseau
added a commit
to AdamBrousseau/openjdk-build
that referenced
this pull request
Jan 20, 2022
This precaution if has been there since it was authored. I can't understand why it is there. The code seems to work without it. It seems to unintentionally be moving those values for every non-milestone release. That is, the code works for milestones only but for releases it moves minor to tags. eg. 0.29.0-m1 becomes 0, 29, 0, m1 which is correct but 0.29.0 becomes 0, 0, 0, 29 which is incorrect Related adoptium#2077 Signed-off-by: Adam Brousseau <adam.brousseau88@gmail.com>
AdamBrousseau
added a commit
to AdamBrousseau/openjdk-build
that referenced
this pull request
Jan 22, 2022
This precaution if has been there since it was authored. I can't understand why it is there. The code seems to work without it. It seems to unintentionally be moving those values for every non-milestone release. That is, the code works for milestones only but for releases it moves minor to tags. eg. 0.29.0-m1 becomes 0, 29, 0, m1 which is correct but 0.29.0 becomes 0, 0, 0, 29 which is incorrect Related adoptium#2077 Signed-off-by: Adam Brousseau <adam.brousseau88@gmail.com>
gdams
pushed a commit
that referenced
this pull request
Jul 6, 2022
This precaution if has been there since it was authored. I can't understand why it is there. The code seems to work without it. It seems to unintentionally be moving those values for every non-milestone release. That is, the code works for milestones only but for releases it moves minor to tags. eg. 0.29.0-m1 becomes 0, 29, 0, m1 which is correct but 0.29.0 becomes 0, 0, 0, 29 which is incorrect Related #2077 Signed-off-by: Adam Brousseau <adam.brousseau88@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removes the
alpha: do not usewarnings and adds the following information to the Json metadata file:openj9-0.22.0)AdoptOpenJDK)openjdk-build/b2a02bb)Also creates a
metadatafolder in the target_dir to contain the metadata files as future additions may cause the artifact list to become cluttered.Resulting Json:
Signed-off-by: Austin Bailey Austin.Bailey@ibm.com