With the release of spring 2.5, if one uses it along with gradle, by default it will generate a library next to your executable jar, when you run the ./gradlew build command. The default start command generated by the JavaProvider in nixpacks is java $JAVA_OPTS -jar -Dserver.port=$PORT build/libs/*.jar. If there are multiple *.jar files in the build/libs folder it can point to the one which is not an executable, in this case the *plain.jar.
When you run the image you'll get the following error:
no main manifest attribute
This is because it tries to execute a jar, which is in reality a library.
Of course the user can modify the gradle.build configuration, to not generate the *plain.jar, however to provide a better user experience that works without requiring user intervention would be a good thing. (Mentioned here: https://github.com/railwayapp/nixpacks/issues/677)
Solution:
From spring v2, there is a dedicated gradle task, called bootJar that only generates an executable jar file. If one modifies the JavaProvider to do this, for gradle + spring applications the problem goes away. However, this means that spring v1 applications won't work anymore.
I can provide a PR, along with the modifications to implement this.
My question is, is it okay to drop the support of spring v1 applications? The last release was back in 2007. I am not sure how many users of nixpacks use spring v1, so that would be an interesting metric also to decide this.
Is there an existing issue for this?
Describe the bug
With the release of
spring 2.5
, if one uses it along withgradle
, by default it will generate a library next to your executable jar, when you run the./gradlew build
command. The default start command generated by theJavaProvider
in nixpacks isjava $JAVA_OPTS -jar -Dserver.port=$PORT build/libs/*.jar
. If there are multiple*.jar
files in thebuild/libs
folder it can point to the one which is not an executable, in this case the*plain.jar
.When you run the image you'll get the following error:
This is because it tries to execute a jar, which is in reality a library.
Of course the user can modify the
gradle.build
configuration, to not generate the*plain.jar
, however to provide a better user experience that works without requiring user intervention would be a good thing. (Mentioned here: https://github.com/railwayapp/nixpacks/issues/677)Solution:
From spring v2, there is a dedicated gradle task, called
bootJar
that only generates an executable jar file. If one modifies theJavaProvider
to do this, for gradle + spring applications the problem goes away. However, this means that spring v1 applications won't work anymore.I can provide a PR, along with the modifications to implement this.
My question is, is it okay to drop the support of spring v1 applications? The last release was back in 2007. I am not sure how many users of nixpacks use spring v1, so that would be an interesting metric also to decide this.
To reproduce
Steps to reproduce the bug:
nixpacks build .
in the project rootno main manifest attribute, in build/libs/app-0.1.1-SNAPSHOT-plain.jar
Expected behavior
The expected behaviour would be that a default spring >= v2.5 project works out of the box without the need to overwrite default configurations.
Environment