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

Find compatible GradleJavaHome and notify client in case of incompatibility #165

Merged

Conversation

Tanish-Ranjan
Copy link
Contributor

@Tanish-Ranjan Tanish-Ranjan commented Jul 4, 2024

Addressing issue 75 and issue 76

@Tanish-Ranjan Tanish-Ranjan changed the title Notify Client on Java Home incompatibility Find compatible GradleJavaHome and notify client in case of incompatibility Jul 13, 2024
@Tanish-Ranjan
Copy link
Contributor Author

Tanish-Ranjan commented Jul 13, 2024

To check if the selected JDK is compatible or not we are now comparing the feature release of the Java Version. Previously, if we retrieved the latest compatible JDK version of say 21 and the client has JDK version 21.0.1. Then Runtime.Version#compareTo it would say the client JDK version is greater than the highest compatible Java version. So I have resorted to using the feature release for compatibility check.

@Tanish-Ranjan
Copy link
Contributor Author

The JDK lookup for gradle seems to be different from the way it is listed in the docs.

Priority order I found out:

  1. Command Line args
  2. Gradle Properties
  3. Installed JDK (gets from the registry I think)
  4. JAVA_HOME (Env variable)

@jdneo jdneo added the enhancement New feature or request label Jul 17, 2024
@jdneo jdneo added this to the 0.4.0 milestone Jul 19, 2024
@jdneo
Copy link
Member

jdneo commented Jul 29, 2024

Hi @Tanish-Ranjan, The PR has some conflicts with the develop branch now. Could you please resolve them?

@Tanish-Ranjan Tanish-Ranjan force-pushed the fix/76-notify-incompatible-java-home branch from 8ed0125 to bb3df6d Compare July 29, 2024 02:34
@Tanish-Ranjan
Copy link
Contributor Author

Prioritizing Gradle default behavior for java home detection with 3b68887

Copy link

@reinsch82 reinsch82 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 to me.

thx

Changes:
- Added a ClientNotifier.java, a utility class for sending notifications to the client.
- LifecycleService now keeps a reference to the BuildClient for sending notifications.
- Updated Launcher.java to set BuildClient on LifecycleService.java
- Added method in utils.java to return the lease compatible Java version.
- Added unit tests in BuildTargetServerIntegrationTest.java to check if the compatibility notifications are returned properly.
Changes:
- Added method to retrieve the GradleJavaHome for the given project.
- Added a new utility class JavaUtils. It contains methods to extract the java version from the JDK file and check java version compatibility.
- Added new test class JavaUtilsTest containing unit tests for methods in JavaUtils.
- Updated LifecycleService to check for GradleJavaHome compatibility before checking JDKs in the preferences.
Changes:
- Updated LifecycleService#getJdkToLaunchDaemon to use feature release for check with selected version.
- Refactored JavaVersion variables for consistency in naming.
- Added unit test for retrieving the oldest compatible java version.
- Updated tests for UserJavaHome to prevent the use of GradleJavaHome for receiving the correct error message on client.
Changes:
- Removed methods for adding originId and taskId to the notification in ClientNotifier.
- Refactored sendNotification to be static and accept the BuildClient directly in the parameter.
- Added a new test case to JavaUtilsTest verifying if IOException is properly thrown in case of non-existent executable.
…s and flattened the logic.

Changes:
- Updated JavaDocs in GradleApiConnector.
- Removed getGradleJavaHome from GradleApiConnector.
- Added getBuildEnvironment method to extract the BuildEnvironment variable directly from the GradleApiConnector.
- Made JavaUtils constructor private and added throws and @nonnull annotations to prevent unwanted exceptions.
- Broke down and flattened the logic for getSuitableJdk from LifecycleService into two separate methods.
- Added getGradleVersion method in LifecycleService to extract the gradle version for the given project.
- Updated getSuitableJdk to getGradleCompatibleJdk to contain only the java home selection logic.
- Added a new method setGradleJavaHome which calls the previous methods to select and set the java home and send notification to the client upon failure.
Tanish-Ranjan and others added 5 commits August 12, 2024 12:03
Changes:
- Removed BuildTargetServerIntegrationTest
- Added IntegrationTest. Base class for integration tests containing the setup.
- Added BuildTargetServiceIntegrationTest. Subclass of IntegrationTest responsible for handling build target integration tests.
- Added LifecycleServiceIntegrationTest. Subclass of IntegrationTest responsible for handling lifecycle integration tests.
Changes:
- Moved methods from IntegrationTest to LifecycleService and BuildTargetService IntegrationTest to keep only the common methods needed by both integration tests.
…compatibility.

Changes:
- Added new method to check compatibility of Java Home with a probe build in GradleApiConnector
- Refactored LifecycleService#setGradleJavaHome to prioritize the default gradle configuration and send a notification to the client if the default behavior is changed.
- Added new test for java home detection with gradle default behavior.
@Tanish-Ranjan Tanish-Ranjan force-pushed the fix/76-notify-incompatible-java-home branch from 3b68887 to cad7692 Compare August 12, 2024 06:41
Copy link
Member

@jdneo jdneo left a comment

Choose a reason for hiding this comment

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

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants