search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.14k stars 587 forks source link

Spring Boot 1.5.x test app is incompatible with Gradle 7 #24080

Open wraschke opened 1 year ago

wraschke commented 1 year ago

The Spring Boot 1.5.x test app is not compatible with Gradle 7; this is the version we need to upgrade to for building Open Liberty so that we can start implementing Jakarta EE 11 features.

Per https://stackoverflow.com/questions/67466790/org-springframework-boot-configuration-with-name-runtime-not-found and https://docs.spring.io/spring-boot/docs/1.5.x/reference/htmlsingle/#getting-started-system-requirements, Spring Boot 1.5 requires 2.9 and 3.x. Later versions of Gradle are not supported.

Running ./gradlew com.ibm.ws.springboot.support.version15.test.app:compileJava results in the following error:

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\liberty\open-liberty\dev\com.ibm.ws.springboot.support.version15.test.app\build.gradle' line: 2

* What went wrong:
An exception occurred applying plugin request [id: 'org.springframework.boot', version: '1.5.9.RELEASE']
> Failed to apply plugin 'org.springframework.boot'.
   > Configuration with name 'runtime' not found.

Obviously, this incompatibility prevents us from upgrading the version of Gradle used to build Open Liberty.

tjwatson commented 1 year ago

I can think of a few ways to get around this issue, none of which I think are great options. I'll list them to get some discussion on possible solutions:

  1. Figure out a way for our build to upgrade to using Java-17 / gradle-7 for everything other than building of the com.ibm.ws.springboot.support.version15.test.app. I think this has really bad negatives - overly complex, requires developers to have tool chains for Java-17 and Java-11.
  2. Change the build of com.ibm.ws.springboot.support.version15.test.app to work with gradle-7. This sounds like the right thing to do, but it has negatives also. It will require either using something different than the gradle plugin org.springframework.boot' version '1.5.X to build or somehow hacking the build to make the version 1.5.X plugin work. Both cases risk building an application that is not a good representation of what a customer would build and deploy to Liberty.
  3. Build the test application JAR outside of our main Open Liberty build and publish the result to Artifactory/DHE and then have the com.ibm.ws.springboot.support_fat pull the binary test application JAR from there to package into the FAT.

Option 3 side-steps all the issues and likely is the quickest to implement, but leaves us with a test JAR that is not maintained by the OpenLiberty source build.

tevans78 commented 1 year ago

For completeness, adding a fourth option:

  1. Don't test Liberty with versions of Spring Boot which are no longer commercially supported by Spring (< v2.4). https://spring.io/projects/spring-boot#support
tjwatson commented 1 year ago

For completeness, adding a fourth option:

  1. Don't test Liberty with versions of Spring Boot which are no longer commercially supported by Spring (< v2.4). https://spring.io/projects/spring-boot#support

That is more of a POC discussion than a design issue discussion involving breaking zero migration and telling customers that may have a support contract with Pivitol for SpringBoot 1.5 that they can no longer run their applications on Liberty.

tjwatson commented 1 year ago

Design call:

Decided to pursue option 3: build and publish the test application to artifactory/DHE as a binary pre-req to the Open Liberty. Need to discuss with @fritze2 on the best way to do the build and publish of the artifact. @anjumfatima90 will investigate updating the tests to use the pre-built artifact.