Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added feature to download boot jdk on demand #3725

Merged
merged 18 commits into from
May 9, 2024

Conversation

judovana
Copy link
Contributor

currenlty only dne for linux, shoudl be easy to extend for windows, not sure what whith other platfroms.

Is done via magic parameter of download for -J: -J download

@github-actions github-actions bot added the windows Issues that affect or relate to the WINDOWS OS label Mar 23, 2024
@judovana
Copy link
Contributor Author

The windows label is wrong. I can not change t on my own. Please fix it to (linux) if possible.
I think I will add windows support once I get some cygwn machine, but it will take time.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A block has been put on this Pull Request as this repository is temporarily under a code freeze due to an ongoing release cycle.

If this pull request needs to be merged during the release cycle then please comment /merge and a PMC member will be able to remove the block.

If the code freeze is over you can remove this block by commenting /thaw.

@judovana
Copy link
Contributor Author

I guess on windows, I will extract

elif [ "$JDK_BOOT_VERSION" -ge 8 ]; then # Adoptium has no build pre-8
# This is needed to convert x86-32 to x32 which is what the API uses
export downloadArch
case "$ARCHITECTURE" in
"x86-32") downloadArch="x32";;
"aarch64") downloadArch="x64";;
*) downloadArch="$ARCHITECTURE";;
esac
releaseType="ga"
vendor="eclipse"
api="adoptium"
apiUrlTemplate="https://api.\${api}.net/v3/binary/latest/\${JDK_BOOT_VERSION}/\${releaseType}/windows/\${downloadArch}/jdk/hotspot/normal/\${vendor}"
apiURL=$(eval echo ${apiUrlTemplate})
echo "Downloading GA release of boot JDK version ${JDK_BOOT_VERSION} from ${apiURL}"
# make-adopt-build-farm.sh has 'set -e'. We need to disable that for
# the fallback mechanism, as downloading of the GA binary might fail
set +e
wget -q "${apiURL}" -O openjdk.zip
retVal=$?
set -e
if [ $retVal -ne 0 ]; then
# We must be a JDK HEAD build for which no boot JDK exists other than
# nightlies?
echo "Downloading GA release of boot JDK version ${JDK_BOOT_VERSION} failed."
# shellcheck disable=SC2034
releaseType="ea"
# shellcheck disable=SC2034
vendor="adoptium"
apiURL=$(eval echo ${apiUrlTemplate})
echo "Attempting to download EA release of boot JDK version ${JDK_BOOT_VERSION} from ${apiURL}"
set +e
wget -q "${apiURL}" -O openjdk.zip
retVal=$?
set -e
if [ $retVal -ne 0 ]; then
# If no binaries are available then try from adoptopenjdk
echo "Downloading Temurin release of boot JDK version ${JDK_BOOT_VERSION} failed."
# shellcheck disable=SC2034
releaseType="ga"
# shellcheck disable=SC2034
vendor="adoptopenjdk"
# shellcheck disable=SC2034
api="adoptopenjdk"
apiURL=$(eval echo ${apiUrlTemplate})
echo "Attempting to download GA release of boot JDK version ${JDK_BOOT_VERSION} from ${apiURL}"
wget -q "${apiURL}" -O openjdk.zip
fi
fi
unzip -q openjdk.zip
mv "$(ls -d jdk-"${JDK_BOOT_VERSION}"*)" "$bootDir"
fi
fi
fi
to the downloader.sh as downloadWindowsBootJDK aybe with some adjustments... thoughts?

@judovana
Copy link
Contributor Author

ps: I had noticed the bash-lint issues, mos tof them are valid. Will elaborate as the review progresses here.

@judovana
Copy link
Contributor Author

Now works for windows and linuxes. I do not have more paltforms to try on. Please consider this.

sbin/prepareWorkspace.sh Outdated Show resolved Hide resolved
makejdk-any-platform.1 Show resolved Hide resolved
build-farm/platform-specific-configurations/downloaders.sh Outdated Show resolved Hide resolved
build-farm/platform-specific-configurations/downloaders.sh Outdated Show resolved Hide resolved
build-farm/platform-specific-configurations/downloaders.sh Outdated Show resolved Hide resolved
@judovana
Copy link
Contributor Author

judovana commented Apr 1, 2024

Thanx a lot for eyball!

@karianna
Copy link
Contributor

karianna commented Apr 2, 2024

@judovana Needs a rebase

@judovana
Copy link
Contributor Author

judovana commented Apr 2, 2024

@judovana Needs a rebase

yup. Thats exactly the reason why I do not want to change the extracted download code in this PR.

judovana and others added 10 commits April 2, 2024 17:09
currenlty only dne for linux, shoudl be easy to extend for windows, not
sure what whith other platfroms.

Is done via magic parameter of `download` for -J: -J download
It seems that the directory was changed in recent times from jdk-8... to
jdk8...
Co-authored-by: Martijn Verburg <martijnverburg@gmail.com>
Co-authored-by: Martijn Verburg <martijnverburg@gmail.com>
Copy link
Contributor

@karianna karianna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm broadly OK with the implementation. Requesting other reviewers

@karianna
Copy link
Contributor

karianna commented Apr 3, 2024

/thaw

@github-actions github-actions bot dismissed their stale review April 3, 2024 02:49

Pull Request unblocked - code freeze is over.

@sxa sxa removed the windows Issues that affect or relate to the WINDOWS OS label Apr 3, 2024
@sxa sxa added p-linux Issues that affect or relate to the ppc LINUX OS z-linux Issues that affect or relate to the s390x LINUX OS labels Apr 3, 2024
@sxa
Copy link
Member

sxa commented Apr 3, 2024

The windows label is wrong. I can not change t on my own. Please fix it to (linux) if possible. I think I will add windows support once I get some cygwn machine, but it will take time.

Tried but I don't trust the labeller not to add windows back in again ;-)

@github-actions github-actions bot added the windows Issues that affect or relate to the WINDOWS OS label Apr 3, 2024
if [ -e "$bootDir" ] ; then
echo "Reusing $bootDir"
else
source "$SCRIPT_DIR/../build-farm/platform-specific-configurations/downloaders.sh"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Architecturally I'm not a fan of this. The stuff in the root of this repository and sbin is supposed to be fully independent. The bits in build-farm is for the adoptium build processes and configures the environment for our setup and wraps around the other stuff. Calling out from sbin to platform-specific-configurations is therefore not ideal.

I like the idea of the option to specify a boot JDK to download, but I think this implementation will need some refinement first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be quite strightforward to move downloaders.sh next to common.sh and refactor them so the $bootDir is not missused.

I will elaborate on the bootDir as I really do not like it. Do you have any prefferences on downloaders.sh location?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm undecided but marginally leaning towards sbin or sbin/common. WDYT @andrew-m-leonard ?

Copy link
Contributor Author

@judovana judovana Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Architecturally I'm not a fan of this. The stuff in the root of this repository and sbin is supposed to be fully independent. The bits in build-farm is for the adoptium build processes and configures the environment for our

Actually there is an misunderstanding, caused by bootJdk variable name clash. I will rework it so it is no longer there.

The if [ -e "$bootDir" ] ; then is independent local check, if boot jdk was already downloaded, so it is not downloaded again.

Pleae advice on downloaders.sh location

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done 00b599c

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmh. I would probably leave the file in build-farm. Just to be sure, that it is clear, where the logic is borrowed from.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm undecided but marginally leaning towards sbin or sbin/common. WDYT @andrew-m-leonard ?

@sxa yes I agree with you, looking at this again I feel uncomfortable that "sbin" code is calling out to "build-farm", as this could lead code-creep in the future architecturally in the wrong direction.
@judovana We should move the downloaders.sh to sbin/common, which is the common place that both sbin and build-farm pull "common" things from please.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, Thanx a lot, on it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. Tested on win x86, el8 aarch64 and f38 x64 aganst jdk8,17 and 21.

@judovana judovana requested review from gdams and sxa April 3, 2024 14:30
@judovana
Copy link
Contributor Author

ping please?

Copy link
Contributor

@andrew-m-leonard andrew-m-leonard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

@judovana
Copy link
Contributor Author

judovana commented Apr 23, 2024

@andrew-m-leonard TY!

@sxa its upt o you now

Architecturally I'm not a fan of this. The stuff in the root of this repository and sbin is supposed to be fully independent. The bits in build-farm is for the adoptium build processes and configures the environment for our setup and wraps around the other stuff. Calling out from sbin to platform-specific-configurations is therefore not ideal.

I like the idea of the option to specify a boot JDK to download, but I think this implementation will need some refinement first.

I had resolved the major issue you had (the global variable) but the shared file remained in build-farm/platform-specific-configurations/downloaders.sh . I left it here, as all the code is originally from build-farm/platform-specific-configurations/ files. Maybe I would vote for leaving it there, with future work on other platforms, and move it only once it have been finished. But that can be very long time, thus the build-farm/platform-specific-configurations/downloaders.sh will be breaking the ' The stuff in the root of this repository and sbin is supposed to be fully independent." which I like, and do not want to be cause of its fade away.

@judovana
Copy link
Contributor Author

judovana commented May 6, 2024

/integrate

if [ -e "$bootDir" ] ; then
echo "Reusing $bootDir"
else
source "$SCRIPT_DIR/../build-farm/platform-specific-configurations/downloaders.sh"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm undecided but marginally leaning towards sbin or sbin/common. WDYT @andrew-m-leonard ?

@sxa yes I agree with you, looking at this again I feel uncomfortable that "sbin" code is calling out to "build-farm", as this could lead code-creep in the future architecturally in the wrong direction.
@judovana We should move the downloaders.sh to sbin/common, which is the common place that both sbin and build-farm pull "common" things from please.

build-farm/platform-specific-configurations/downloaders.sh -> sbin/common/downloaders.sh
@judovana
Copy link
Contributor Author

judovana commented May 7, 2024

done. Tested on win x86, el8 aarch64 and f38 x64 aganst jdk8,17 and 21.

rm -rf "${BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}/installedalsa" || true
rm -rf "${BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}/installedfreetype" || true
rm -rf "${BUILD_CONFIG[WORKSPACE_DIR]}/downloaded-boot-jdk-${BUILD_CONFIG[OPENJDK_FEATURE_NUMBER]}" || true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to suggest leaving this in place as a cache for anyone using our scripts since the JDK is quite a big download, but I'm also ok with this.

I was going to comment on the fact that || true is unnecessary with rm -f but sine that's also in the previous three lines I'll ignore it ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, and I'm keeping it. It will be removed only if if [[ "${BUILD_CONFIG[CLEAN_LIBS]}" == "true" ]]; then
oook? Yah, I was wondering on the double passig rf || true, but left in the style!

Copy link
Member

@sxa sxa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM and I've very happy to see all of this logic moved out of the platform-specific-configurations directory :-)

I've done a few tests on Linux but not Windows.

In the future we should look at doing the same for AIX, Solaris and macos so I suggest creating an issue for that since I'm not going to mandate that we do it now.

Also, one other question for anyone else reading this - should we default to download if we can't find a JDK in any other location?

@judovana
Copy link
Contributor Author

judovana commented May 9, 2024

/integrate

@judovana
Copy link
Contributor Author

judovana commented May 9, 2024

LGTM and I've very happy to see all of this logic moved out of the platform-specific-configurations directory :-)

I've done a few tests on Linux but not Windows.

In the future we should look at doing the same for AIX, Solaris and macos so I suggest creating an issue for that since I'm not going to mandate that we do it now.

Also, one other question for anyone else reading this - should we default to download if we can't find a JDK in any other location?

that would be NACK by me. It is not small dependence, and one should have boot jdk around. The -J download is highly comfortable option

issue created: #3804

Copy link
Contributor

@andrew-m-leonard andrew-m-leonard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

@andrew-m-leonard andrew-m-leonard merged commit 07d523c into adoptium:master May 9, 2024
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p-linux Issues that affect or relate to the ppc LINUX OS windows Issues that affect or relate to the WINDOWS OS x-linux Issues that affect or relate to the x64/x32 LINUX OS z-linux Issues that affect or relate to the s390x LINUX OS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants