Clear up directory naming scheme inside archives

[johnoliver]

We need to decide what our dir naming scheme is inside our archives.

Currently we output dirs of the form:

jdk-8.0.202
jdk-8.0.202-jre
jdk-12.0.0
jdk-12.0.0-jre

I.e the semver version without any build numbers. In the past dirs were of the form:

jdk8u202-b08
jdk8u202-b08-jre
jdk-12+33
jdk-12+33-jre

I.e the openjdk version number including build.

Currently there is a mismatch between what the installers are accepting as a dir and what we produce. Recently the build number was removed in #1012 to help the installers but this does not seem to have worked. Can we agree on a format and make sure the installers are in sync. My preference would be:

jdk-8.0.202+8
jdk-8.0.202+8-jre
jdk-12.0.0+33
jdk-12.0.0+33-jre

I.e semver including build

[johnoliver]

also possible option of adding aojdk to make it clear that it is us

[sxa]

I quite like the current (nightly build) format, although as per John's comment I think it would be good to have aojdk at the start if there were no objections as it's useful to identify what's what when doing an ls in /usr/lib/jvm on my machine :-)

It might be worth collating what all other providers are doing with the directory name in here to help get a consensus.

[johnoliver]

I am happy to keep it as:

jdk-8.0.202
jdk-8.0.202-jre
jdk-12.0.0
jdk-12.0.0-jre

or move to

aojdk-8.0.202
aojdk-8.0.202-jre
aojdk-12.0.0
aojdk-12.0.0-jre

Just need to fix the windows installer to make sure they understand the format

[sxa]

I've got a feeling we have discussed this somewhere previously but could we not avoid jdk in the jre case? i.e.

aojdk-8.0.202
aojre-8.0.202
aojdk-12.0.0
aojre-12.0.0

[lumpfish]

With this convention all variants (openjdk-hotspot and openjdk-openj9) have the same top level directory, so they cannot be unzipped side by side (and it is not obvious from the directory name which variant it is).

[aahlenst]

What about compiling a list of requirements first? Like:

• Hotspot and OpenJ9 can be in the same directory
• OpenJDK 8..12 can be in the same directory
• Semver (e.g. 8.0.202) instead of upstream naming scheme (8u202)
• …

This should make it easier to evaluate each proposal for its (dis-)advantages.

[sxa]

So what is your preference @lumpfish? Something like this? We could omit "hotspot" as it would be considered the "default", or squash hotspot and openj9 to hs or oj9.

aojdk-8.0.202-hotspot
aojdk-8.0.202-openj9
aojre-8.0.202-hotspot
aojre-8.0.202-openj9
aojdk-12.0.0-hotspot
aojdk-12.0.0-openj9
aojre-12.0.0-hotspot
aojre-12.0.0-openj9

[sxa]

I'm normally completely against specifically asking people to retweet anything but if you want to help get others involved in this since I'm sure there are many views out there feel free to RT this link to the issue :-) https://twitter.com/sxaTech/status/1116287512207593472

[lumpfish]

I think the directory should make it clear where the content came from and what is in it, such as

adoptopenjdk-jre-8.0.212_openj9-0.14.0

or more generally

adoptopenjdk-jre-openjdk-level_variant

eclipse/openj9 have a clear versioning convention of their own so a specific 'variant' name is easy to define.

I'm not aware of a similar versioning system for hotspot (or corretto etc.), so perhaps simply 'hotspot' is appropriate.

[sxa]

I personally don't like such long directory names on my file system, although I can understand why openj9 might want their version number in there, although it's rare for it to change for a given JDK update and not be implicit for any given release.

[keithc-ca]

I prefer shorter directory names as well, but clarity to me is more important than brevity.

As part of this 'cleanup' can we remove the redundancy in URLs? For example, _openj9 appears twice in the filename OpenJDK8U-jdk_x64_linux_openj9_8u202b08_openj9-0.12.1.tar.gz:

https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u202-b08_openj9-0.12.1/OpenJDK8U-jdk_x64_linux_openj9_8u202b08_openj9-0.12.1.tar.gz

[karianna]

We will delay resolving this until after the 8u212 release.

[smlambert]

+1 on short names (especially given file name limits on Windows, we hit issues in testing where full path name is exceeded)

Also prefer to have the implementation explicitly named, hs or oj9 (or hotspot / openj9), or as was suggested any others that may be built or served up from AdoptOpenJDK (makes it easier from automation/scripting perspective).

[M-Davies]

To add to this issue, recent work with the installer has shown that it struggles to work with the JDK-Next binaries since they have no version number on their names (see #1712 and Slack).

To resolve parsing errors in the installer and sign jobs, I'd prefer for the Major version number of the current JDK-Next added to the first field of the binary to make them like all of the other binaries.

I.e.
OpenJDK-jdk_x64_windows_hotspot_2020-03-27-03-31.zip is now OpenJDK15-jdk_x64_windows_hotspot_2020-03-27-03-31.zip OR `OpenJDK15U-jdk_x64_windows_hotspot_2020-03-27-03-31.zip

This would require changes to our job regenerator, config and some misc changes in openjdk-build-pipeline This should only require an additional check in openjdk-build-pipeline

[M-Davies]

Any opinions on the above?

[smlambert]

I think it makes sense to apply the jdkNext version number the moment it is known (know in build pipeline, then change can be made there), so that scripts/jobs do not have to each have special handling of the "Next" string, but so they can behave as they do for the LTS versions and current active version.

[M-Davies]

Ok so in that case, it would involve setting the javaVersion in the pipeline configs to jdk15u and then updating the rest of the pipeline steps to match this change. I can look into that tomorrow

[M-Davies]

@smlambert Just looking at this again, I can identify some inital changes M-Davies@0e1f298.

This doesn't include anything outside of the build repo however, so extra changes to the installer (I can think of at least one over there on the top of my head) and other Adopt projects will likely need some tweaking to adapt to the new format.

[M-Davies]

Propose the removal of the link between the openjdk repository from which the code is being taken (jdkNN / jdkNNu) and the resulting build files names - i.e. name the build files OpenJDKnn.xxxxx throughout the entire life cycle of the release.

Originally posted by @lumpfish in #1654

[M-Davies]

Ref #2000 (comment), is this issue on hold while the transfer to Adoptium is ongoing?