fix/#979 fix springboot running plain jar instead of executable jar #980
Conversation
src/providers/java.rs
Outdated
| @@ -95,11 +96,20 @@ impl JavaProvider { | |||
| } | |||
| } | |||
|
|
|||
| fn get_gradle_build_cmd(&self, build_gradle_content: &String, gradle_exe: &String) -> String { | |||
| if self.is_using_spring_boot(build_gradle_content) { | |||
There was a problem hiding this comment.
Is it possible to detect if Spring v1 is used and only use bootJar if it is version 2+?
There was a problem hiding this comment.
One can read it from the build.gradle file, however I would not go that way. There can be edge cases, where a gradle plugin update or a spring version update changes the versioning scheme. Also one can define it in kotlin and groovy. That makes capturing this a little bit finnicky and I would not want to rely on a bunch of regexp expressions.
If nixpacks would like to support spring v1 as well, there is an alternative solution to what I've provided in this PR. Which is the following:
- The problem is that a
*plain.jaris being generated along with an executable.jar - The start command can point to the
*plain.jarinstead of the executable - As a solution one can adjust the start command with the following one-liner:
java $JAVA_OPTS -jar -Dserver.port=$PORT $(ls -1 build/libs/*jar | grep -v plain) - So basically instead of configuring gradle to create only an executable jar, we use
lsandgrepto find the executablejarinstead of theplainone - This way it doesn't matter what spring or gradle version is being used, the only thing that matters is that the jars are being generated in the
build/libsfolder and there is only one executable jar
What do you think about this approach?
There was a problem hiding this comment.
I think that solution works! And yeah, supporting v1 isn't 100% necessary, but backwards compatibility is always nice, especially if the solution is as simple as greping for the executable jar
There was a problem hiding this comment.
I've updated the PR with the new solution
There was a problem hiding this comment.
Is it possible for me to get a review here? And then I can check whether all the pipelines are green or not. Thank you!
fattila16
force-pushed
the
fix/979-fix-springboot-running-plain-jar-instead-of-executable-jar
branch
6 times, most recently
from
7440d78
to
f84dea6
Compare
fattila16
force-pushed
the
fix/979-fix-springboot-running-plain-jar-instead-of-executable-jar
branch
from
c451919
to
1235ef6
Compare
…cutable jar file if gradle is used, and blacklists plain.jar files Co-authored-by: Tibor Toth <toth.t11@gmail.com>
be sure that the adjusted start cmd is backwards compatible Co-authored-by: Tibor Toth <toth.t11@gmail.com>
…art cmd for gradle Co-authored-by: Tibor Toth <toth.t11@gmail.com>
fattila16
force-pushed
the
fix/979-fix-springboot-running-plain-jar-instead-of-executable-jar
branch
from
1235ef6
to
de94abe
Compare
|
Thank you 🎉 |
This PR solves the following issue: #979
Disclaimer: This drops support of any spring version that does not have abootJartask, mainly spring v1Adjust theJavaProviderso that it usesbootJarto build an executable JAR instead ofbuildwhich generates a*plain.jaralso when spring and gradle is detectedAdd e2e test cases for spring v2 and v3, also remove spring v1Update the docs of theJavaProviderso that it has information regarding the spring version support, and the build commandsAs per the comments below PR implements a different solution now:
JavaProviderso that if gradle and spring is detected then the start cmd includes a one line to find the executable jar and blacklists the plain.jarJavaProviderso that it includes description for the new start cmd if gradle and spring is detected