initializr VS Spring Boot

The best way, for generating a ready-to-run application in Java you can use the Spring Boot Initializr tool.

curl --location 'https://start.spring.io/starter.zip?type=maven-project&language=java&bootVersion=3.2.2&baseDir=ms-xcoffee&groupId=com.xcoffee&artifactId=ms-xcoffee&name=ms-xcoffee&description=Demo%20project%20for%20Spring%20Boot&packageName=com.xcoffee.ms-xcoffee&packaging=jar&javaVersion=21&dependencies=webflux%2Clombok%2Cvalidation' | tar -xzvf -

In this segment we will create a basic Spring boot app from Spring Initializer. Add the below dependencies:

Add the following MongoDB dependencies in your pom.xml or use spring initializer and select the Spring Data MongoDB dependency:

I created all of these applications using start.spring.io's REST API and HTTPie.

An easy way to create the skeleton project is to visit Spring Initializr, I set the Project to Gradle - Groovy, Language to Java, and add Spring Web dependency. Then it's just to generate the project and unpack it.

Create a new Spring Boot application using the Spring Initializr. You can use the web version or the curl command below. Use the default for most of the options. For the dependencies, select web, and okta. For the build tool, select Gradle.

I will start with a simple example of a cloud function, which is the same as a rest endpoint in the classical spring boot web application. You can create a project from your favorite IDE or from Spring Initliazr.

I would advise everyone to go the extra mile and update their entire spring boot version to the latest appropriate version. To find out what that is, simply go to https://start.spring.io.

- Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spr...

I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.

https://github.com/spring-projects/spring-boot/pull/39754/co...

If you’re currently running with an earlier version of Spring Boot, I recommend that you upgrade to Spring Boot 2.7 before migrating to Spring Boot 3.0. It minimizes compatibility issues as much as possible.

Okay, we need to build the game? No problem, we will use Spring Boot and Swing!

It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this:

https://github.com/spring-projects/spring-boot/issues/33044

Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic.

An interested reader can decide for themselves:

https://github.com/spring-projects/spring-boot/tree/main/spr...

Explicitly decoding URL query parameters occurs less often because many frameworks, including Spring Boot, handle decoding automatically.

https://aws.amazon.com/lambda/ https://aws.amazon.com/api-gateway/ https://aws.amazon.com/serverless/sam/ https://aws.amazon.com/cloudformation/ https://aws.amazon.com/s3/ https://spring.io/projects/spring-boot https://start.spring.io