Consider adjusting Spring Boot-related wording of WAR deployment using Spring Boot feature vs. more-standard WAR deployment

[scottkurz]

As the draft blog post OpenLiberty/blogs#3655 explains, a Spring Boot WAR can be deployed like any Java EE / Jakarta WAR.

The feature enables the "thinning", bootstrapping via a main() rather than using the servlet initializer, the use of app args, maybe some extra config?, and also the ability to use a JAR package.

However doing a more typical WAR deployment has some advantages too...e.g. you can use dev mode, you can use the default liberty-maven-plugin deployment (so you can deploy like your other WARs).

We don't really discuss this in the doc.

Ideally the lack of dev mode support for Spring Boot is just a point-in-time statement that will eventually be resolved, but there's not a current near-term plan for that.

CC @cbridgha @hlhoots

[dmuelle]

Consolidating here from #7284
Do we need a doc process for capturing items like this somewhere?

support for 3.2 thinning in 24.0.0.1: OpenLiberty/open-liberty#27276

[dmuelle]

Hi @scottkurz - now that the standard WAR process to deploy an SB app is documented in your blog post, I've added clarification and a link to the main SB doc:

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/deploy-spring-boot.html#deploy

Before we go into the CLI steps, we provide a link to the SB guide for those who want to use Maven. I added an additional statement that you can deploy an SB app like any other WAR and pointed to the post for more info. We don't often link to blog posts from the docs, but in this case I think it makes sense, particularly since the lack of dev mode support for Spring Boot is just a point-in-time statement that will eventually be resolved. We can review this doc when/if that happens and edit as needed.

lmk what you think, thanks

[scottkurz]

Before we go into the CLI steps, we provide a link to the SB guide for those who want to use Maven. I added an additional statement that you can deploy an SB app like any other WAR and pointed to the post for more info. We don't often link to blog posts from the docs, but in this case I think it makes sense, particularly since the lack of dev mode support for Spring Boot is just a point-in-time statement that will eventually be resolved. We can review this doc when/if that happens and edit as needed.

lmk what you think, thanks

I took a look. I like the basic idea as an interim step until we do something better.

I think, though, it might be a better organizational fit to include the new paragraph somewhere in the initial section, that is BEFORE we get to the individual sections like the #deploy-anchored one.

All of the information in the subsections after
https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/deploy-spring-boot.html#deploy
relates to what I called the "optimized" deployment.

So IMO the best flow is to mention the alternative of a regular deployment earlier.

If that seems too long dragging out the intro maybe something shorter like:

As an alternative to using the optimized Spring Boot deployment described here, you can also deploy a Spring Boot WAR application using the same server configuration as with any standard Jakarta EE WAR . For more information, see the Running a Spring Boot 3.x application WAR file on Liberty blog post.

[dmuelle]

Thanks Scott- updated

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/deploy-spring-boot.html

[scottkurz]

Thanks Scott- updated

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/deploy-spring-boot.html

I like that. It looks good. Two minor comments:

1. sections,you => sections, you (missing a ' ')
2. This probably needs a bit of qualification scoping it to a WAR. In contrast, the next paragraph talks about how the rest of the doc applies to JAR + WAR equally.

So how about either:

"As an alternative to using the optimized Spring Boot deployment described in the following sections, you can also deploy a Spring Boot WAR application like any standard Jakarta EE WAR. "

or:

"For a WAR application, as an alternative to using the optimized Spring Boot deployment described in the following sections, you can also deploy a Spring Boot application like any standard Jakarta EE WAR. "

[dmuelle]

Thanks Scott- Ive got that edit in the updated draft.

The other piece of this is figuring out whether we need to update the thinning guidance-

Do we need a doc process for capturing items like this somewhere?
support for 3.2 thinning in 24.0.0.1: OpenLiberty/open-liberty#27276

should we declare thinning support separately from our guidance for the SB feature in general?

• If your application uses Spring Boot 1.5.8+, enable the springBoot-1.5 feature.
• If your application uses Spring Boot 2.0.1+, enable the springBoot-2.0 feature.
• If your application uses Spring Boot 3.0.4+, enable the springBoot-3.0 feature.

If so- how should we describe support levels currently? In this case I think we need to handle all future updates to thinning support on the dev side by tracking them in an epic with at least ID Trivial label.

[scottkurz]

FIRST

Thanks Scott- Ive got that edit in the updated draft.

I like this. Let me just ask... you don't think it's confusing to see this:

As an alternative to using the optimized Spring Boot deployment described in the following sections, you can also deploy a Spring Boot application like any standard Jakarta EE WAR. For more information, see the ....

followed by:

Although the examples in the following sections use an example JAR application file, the Open Liberty configuration is the same for JAR and WAR files.

do you? I just mentioned a difference for WAR.. now I'm saying the config is the same for JAR/WAR??

Would this help clarify the flow and the alternatives more?

Although the examples in the following sections ... the Open Liberty configuration for the optimized Spring Boot deployment is the same for JAR and WAR files.

SECOND

The other piece of this is figuring out whether we need to update the thinning guidance-

I'm going to defer on that to @cbridgha maybe. No opinion there, I only mentioned it seeing some internal Slack questions popping up.

[dmuelle]

Closing as completed- if/when development introduces minor features for SB or changes delivery of thinning support, we'll revisit.