Rework "Running a Spring Boot 3.x application WAR file on Liberty" blog post

[scottkurz]

NOTE

From (IBM-internal) Slack discussion: https://ibm-cloud.slack.com/archives/CJ6U2DWPJ/p1706559186999469

I would like to rework the article: "Running a Spring Boot 3.x application WAR file on Liberty" to highlight a few points on the developer experience of taking a simple, existing SpringBoot app and targeting Liberty:

WAR case

First, if you're going to switch to WAR packaging then you can leverage the liberty-maven-plugin's dev mode.

A couple of the tasks in the post are necessary: creating the SpringBootServletInitializer and adding the packaging type to the pom.xml. OTOH, a couple tasks are unnecessary, e.g. configuring liberty-maven-plugin in pom.xml or running mvn package before running the app and providing a server.xml.

JAR case

Though it'd be possible to stop there, (and perhaps we should even), I'd like to consider going further and discussing the DevEx for the JAR-packaged case.

We don't have dev mode support for SpringBoot JARs currently. The best Developer Experience for iterating through local development, then, would probably involve adding <deployPackages>spring-boot-project</deployPackages> to the pom.xml, launching via: mvn package liberty:run and updating via mvn package liberty:deploy.

While this is not as seamless as dev mode it's not awful either and worth learning if you are iterating through dev of a SB-on-Liberty application today.

DOCKER

We should just be aware of the Docker build we are promoting, once development is over, e.g. in :

• https://openliberty.io/blog/2023/09/26/spring-boot-3-instant-on.html
• https://github.com/openliberty/guide-spring-boot.git

and make sure what we describe in the JAR case doesn't conflict in any awkward way with any of that.

REMAINING TODOs LEFT AS-IS:

Creating the blog posts

The Open Liberty release blog posts are written in asciidoc and pushed to the OpenLiberty/blogs repo. The repo README contains instructions on how to create, build, and review the posts, including template files to help you.

You need to create two separate posts:

• a GA release blog post
• a beta release blog post

Follow the instructions in the README and the template file to complete the following tasks for each post:

• Create a draft blog post using the GA release blog post template or the beta release blog post template. Build the draft blog post on the draft website according to the blog post instructions.
• When you've compiled the whole blog and checked that it makes sense to the best of your knowledge, create a PR from your feature branch to the staging branch (as described in the blog post instructions).
• Get the draft post reviewed by all the people who contributed the content to the blog post.
• Then, when they're all happy, ask @mbroz2 to review it.
• Agree with @mbroz2 which feature will lead this blog post, then write a title, slug, summary first paragraph, and SEO front matter appropriately.
• Add relevant tags to the post in the staging branch (see the blog post instructions).
• Get the post approved by @mbroz2.
• On release day (usually Tuesday for the GA release post and Thursday for the beta release post), @mbroz2 will publish the post.

All done?

Check that you've completed every task above. Select each check box to confirm that you have before closing this issue.

[lauracowen]

@dmuelle @GraceJansen As this was published so long ago, the updated version should probably be published with a new date. To do that, publish as a new post then set a redirect from the old post to the new post so that we don't have the old one floating around but we still have any google juice for it.

[scottkurz]

@lauracowen would you suggest as a next step here? I also asked for comments in internal Slack. Did I ask too many people ? :)