search

adoptium / temurin-build

Eclipse Temurin™ build scripts - common across all releases/versions
Apache License 2.0
1.02k stars 247 forks source link

Clear up directory naming scheme inside archives #1016

Open johnoliver opened 5 years ago

johnoliver commented 5 years ago

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 commented 5 years ago

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

sxa commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

What about compiling a list of requirements first? Like:

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

sxa commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

smlambert commented 5 years ago

+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 commented 4 years ago

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 https://github.com/AdoptOpenJDK/openjdk-build/issues/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 commented 4 years ago

Any opinions on the above?

smlambert commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@smlambert Just looking at this again, I can identify some inital changes https://github.com/M-Davies/openjdk-build/commit/0e1f298f8143a196e4d6ba6e8f7cc67046d09c93.

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 commented 4 years ago

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 https://github.com/AdoptOpenJDK/openjdk-build/issues/1654

M-Davies commented 4 years ago

Ref https://github.com/AdoptOpenJDK/openjdk-build/issues/2000#issuecomment-666265364, is this issue on hold while the transfer to Adoptium is ongoing?