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

[Gradle JDK Automanagement] Install only used JDKs #479

Open
wants to merge 16 commits into
base: develop
Choose a base branch
from

Conversation

crogoz
Copy link
Contributor

@crogoz crogoz commented Dec 9, 2024

Before this PR

Atm we are generating jdk configurations for all jdks that are configured by gradle-jdks-latest. This means extra work if the repository only uses a subset of those JDKs. This is especially relevant in the context of circle VMs - we end up installing jdks that might not be used during circle ci jobs.

After this PR

Continuation for: #472.

  • We are only generating the jdk configuration files for the used java versions - depends on the application of the gradle-baseline plugins.
  • Adding an command line option gq generateGradleJdkConfigs --includeAllJdks that can generate all the jdk configuration files. Required by the excavator runs internally,

==COMMIT_MSG==
Install only used JDKs
==COMMIT_MSG==

Possible downsides?

@crogoz crogoz marked this pull request as ready for review December 9, 2024 12:57
Comment on lines 48 to 55
/**
* Option to include a specific java major version when generating/checking the gradle jdk configuration files.
*/
@Input
@Option(
option = "includeJava",
description = "Generates the jdk configuration directories for the Java major version.")
public abstract SetProperty<String> getIncludedJavaMajorVersion();
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we could avoid this if we were to regenerate the jdk configs at the same time (ie same gradle invocation in excavator) as bumping the versions? The problem should only present itself when changing the versions used, then trying to run gradle again but the wrong JDKs are included. I think we might be able to do that.

If that doesn't work, I think I'd prefer an option to just use all the configured versions rather than including specific ones. That way we don't need to keep updating excavators with specific versions, they can just include everything they need.

Copy link
Contributor Author

@crogoz crogoz Dec 9, 2024

Choose a reason for hiding this comment

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

I think we could avoid this if we were to regenerate the jdk configs at the same time (ie same gradle invocation in excavator) as bumping the versions? The problem should only present itself when changing the versions used, then trying to run gradle again but the wrong JDKs are included. I think we might be able to do that.

I am not sure how that would work. If we want to bump a version of jdk used (eg. javaVersions libraryTarget = 21), when running any gradle task ./gradlew setupJdks we don't have the jdk files configured so we are not installing anything. Then if jdk 21 doesn't exist, gradle will complain during the configuration phase that no toolchain was found for java == 21 when it was configuring eg. javaCompiler.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, makes sense, of course we have to do it in two invocations.

I think I'd just prefer the option then to use all the JDKs rather than opting into specific ones.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if this should just be something you can set via an environment variable instead, so we can just set export GRADLE_JDKS_INSTALL_ALL_JDKS=true in the excavator and not have to worry about it setting it on all the different commands.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also probably need a test for this behaviour, whatever it ends up being.

@crogoz crogoz requested a review from CRogers December 11, 2024 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants