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

Upgrade Java to v17 #1823

Closed
28 tasks done
techcobweb opened this issue Apr 10, 2024 · 2 comments
Closed
28 tasks done

Upgrade Java to v17 #1823

techcobweb opened this issue Apr 10, 2024 · 2 comments
Assignees

Comments

@techcobweb
Copy link
Contributor

techcobweb commented Apr 10, 2024

Story

As a galasa test developer, I want to use a supported JVM level, and some features of Java (which were added after v11 was shipped) in my Galasa tests.

Background

(These tasks are for creating pull requests, not merging, so these may not be done)
Maven:

  • integratedtests
  • cli/pkg/embedded/templates/projectCreate/parent-project/pom.xml
  • maven
  • simplatform
  • wrapping
  • Buildutils
  • Framework

Gradle:

  • Framework
  • managers
  • obr
  • webui
  • extensions
  • integratedtests

Other:

  • Automation
  • Update Dockerfile From references:
    • webapp (requires tomcat 11, jdk 21)
    • openapi
    • openjdk11-ibm
    • openjdk11-ibm-gradle
    • swagger
    • simplatform-amd64
  • Update tekton pipelines
    • automation
    • cli
    • codecoverage
    • obr-generic
    • run-tests? (uses local.CoreLocalJava11Ubuntu)
    • simplatform (pr only)
  • Update tekton tasks
    • gradle-build
    • maven-build
@Wyvinar
Copy link

Wyvinar commented Jun 27, 2024

How I upgraded Gradle locally:
used sdkman to install Gradle 8.8 (sdk install gradle 8.8)
used the sdk home gradle 8.8 command to find it's home
added [gradle-home]/bin to path (replacing the v6 path)

@techcobweb
Copy link
Contributor Author

@KirbyKatcher Wondering if the objects that are built will still run on java 11. They need to...
If you find any reason they won't then could you pls come talk about it ?
I imagine the binary class files are targeting Java 1.8, but I'm wondering what we actually test...

Wondering if the ecosystem needs to target a different docker image to run in the container for tests, and whether the helm installer admin gets to say which version of Java they are running ?

It might be better if a cps property held the java version/docker image name which gets launched ?
Then tests could override it perhaps ? We probably need more discussion on this also.

For local build processes, I guess we don't have to do anything except pre-req Java 17, but for the build process, what other tests do we need to put in place to test Java 11 and 17 ?

Suggestions welcome @jadecarino @eamansour

@KirbyKatcher KirbyKatcher moved this from 🔖 3 Iteration Backlog to 🏗 2 In progress in galasa-dev team Jul 16, 2024
@KirbyKatcher KirbyKatcher moved this from 🏗 2 In progress to 🔖 3 Iteration Backlog in galasa-dev team Jul 18, 2024
@techcobweb techcobweb moved this from 🔖 3 Iteration Backlog to 4 Release backlog in galasa-dev team Jul 22, 2024
@KirbyKatcher KirbyKatcher moved this from 4 Release backlog to ✅ Done - in iteration in galasa-dev team Aug 22, 2024
jt-nti added a commit to jt-nti/galasa.dev that referenced this issue Sep 17, 2024
jt-nti added a commit to jt-nti/galasa.dev that referenced this issue Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment