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

Script in distribution ZIP (created with Gradle application plugin) vs fully executable JAR #26410

Closed
mauromol opened this issue May 7, 2021 · 2 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@mauromol
Copy link

mauromol commented May 7, 2021

Currently the reference guide for the Spring Boot Gradle plugin says little about the scripts that are generated inside a ZIP/TAR file produced when applying the application plugin and running the bootDistZip or bootDistTar tasks:

https://docs.spring.io/spring-boot/docs/2.4.4/gradle-plugin/reference/htmlsingle/#publishing-your-application-distribution

In particular, I was wondering whether those scripts may be used to install my Spring Boot app, for instance in a Linux/Unix environment, instead of using the scripts embedded into a "fully executable JAR":

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#deployment-install

I understand that "fully executable JARs" have some drawbacks, like the fact that the produced JARs are not 100% compatibles with all tools (including jar -xf, for instance). So, it would be interesting whether the use of the application plugin may be seen as an alternative approach or rather the produced scripts in that case are much more "basic".

If the latter applies, it would be nice to know whether you may consider an interesting option to improve those scripts to provide an alternative way of generating boot artifacts that can be installed as Linux services without the need for "fully executable JARs", or rather you would discourage such an approach.

In any case, I would suggest to at least improve the Gradle plugin documentation to make it clear what is the scope of the scripts provided by the bootDistZip or bootDistTar tasks, with particular regards to the recommended ways to install/launch Spring Boot applications mentioned in the main Spring Boot reference documentation.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 7, 2021
@wilkinsona
Copy link
Member

wilkinsona commented May 7, 2021

So, it would be interesting whether the use of the application plugin may be seen as an alternative approach or rather the produced scripts in that case are much more "basic".

The scripts are very similar to those included in the standard distribution that the application plugin can produce. The one notable difference is that they launch the application as a fat jar (or war) using java -jar.

If the latter applies, it would be nice to know whether you may consider an interesting option to improve those scripts to provide an alternative way of generating boot artifacts that can be installed as Linux services

That's really out of scope. As described above, the scripts are modelled very closely on those that Gradle generates by default and we want that to remain the case.

In any case, I would suggest to at least improve the Gradle plugin documentation to make it clear what is the scope of the scripts provided by the bootDistZip or bootDistTar tasks

I think the documentation already covers this in section 6.3 where it says:

When the application plugin is applied a distribution named boot is created. This distribution contains the archive produced by the bootJar or bootWar task and scripts to launch it on Unix-like platforms and Windows

and in section 9.5 where it goes into some more detail:

Creates a CreateStartScripts task named bootStartScripts that will create scripts that launch the artifact in the bootArchives configuration using java -jar

To avoid the documentation being too verbose, we assume familiarity with what the application plugin usually does (and link to its documentation) and prefer just to document the differences. In this case, the difference is the use of java -jar in the scripts which is already covered. Thanks anyway for the suggestion.

@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels May 7, 2021
@scottfrederick
Copy link
Contributor

"fully executable JARs" have some drawbacks, like the fact that the produced JARs are not 100% compatibles with all tools

This should be addressed by #22336.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

4 participants