Modified guide to enable Spring Boot Docker Compose support

[robertmcnees]

This PR updates the guide by simplifying access on an external dependency, RabbitMQ. The original guide was written before Spring Boot introduced support for Docker Compose. The user can now simply run the application and allow Spring Boot to find the compose.yaml file automatically. This simplifies the steps and external dependencies for new users.

The majority of the guide remains unchanged other than how to build and execute the final product. In pursuit of that goal, several items were changed.

• Maven and Gradle wrappers were updated
• Build files were modified to include the spring-boot-docker-compose dependency (4 files in total - build.gradle and pom.xml in both the complete and initial folders)
• Docker compose filename changed to what comes from Spring Initializr, that is compose.yaml
• compose.yaml contents changed to match what comes from Spring Initializr exactly
• Added a compose.yaml to the initial folder
• Significant changes to the previous section Build an executable JAR

Previously the guide walked the user through building an executable jar, but that section needed to be rewritten given the reliance on Spring Boot Docker compose. While rewriting that section, I added additional content on using buildpacks and native images. Whereas the previous guide only focused on building an executable jar, this update proposes walking the user through 4 ways to build the application.

This PR should address issues #41 #39 #37

[artembilan]

LGTM

[robertmcnees]

I wrote some content in this guide that I hope will be the foundation for other guide updates. It would be great to get a review from a few:

• @artembilan - thank you for providing a review on the content!
• @sdeleuze - could you review the part about native compilation at the end of the README? I had to write a custom hint.
• Spring Boot team - could you review the content around Spring Boot Docker Compose support?
• Spring Data team (optional) - possibly @mp911de - we have a lot of guides that could benefit from a similar approach in Data - If this looks OK I will take the same pattern to those guides
• @Buzzardo - content review

[mp911de]

It makes sense to use Docker Compose for our Data-related guides requiring a running database such as Neo4j, MongoDB, Cassandra.

[sdeleuze]

@artembilan @robertmcnees I am wondering if we could use an annotation-based programming model variant that allows to express that receiveMessage() is a message listener instead of new MessageListenerAdapter(receiver, "receiveMessage"). If that's possible, that would remove the need for native hints and would be cleaner from a programming model perspective.

[artembilan]

@sdeleuze .

Yes, that would be easier and simple, but if you follow this guide by itself, it talks exactly about such a POJO approach via MessageListenerAdapter.
Plus with exposing that native hint we would point how to deal with then in the target application when the approach is not annotation based.

Does it make sense?

[robertmcnees]

@sdeleuze @artembilan I can remove the sections on building native if it doesn't fit with the guide.

Native is in this guide because I'm experimenting with a new common format for building all of our guides. I know this PR doesn't reference that file but the text should be the same. I plan to update this PR or have a new one to include the shared instructions. This is one of the first Guides I'm experimenting with the new format.

[Buzzardo]

Change More information about this can be found to You can find more information

[Buzzardo]

Change the period at the end to a colon

[Buzzardo]

Change the period at the end to a colon

[Buzzardo]

Change to:

You can then run the ./gradlew nativeCompilecommand to generate a native image. When the build completes, you can run the code with a near-instantaneous startup time by running the build/native/nativeCompile/{build_name} command.

[Buzzardo]

Change to:

You can also create a https://docs.spring.io/spring-boot/docs/current/reference/html/native-image.html#native-image.developing-your-first-application.buildpacks[Native Image using Buildpacks^]. Provided that the Gradle plugins block contains org.graalvm.buildtools.native, you can generate a native image by running the ./gradlew bootBuildImage task. Once the build completes, you can start your application with the docker run --network container:guide-rabbit docker.io/library/{build_name}:{build_version} command.

[sdeleuze]

@artembilan If this is our official RabbitMQ guide, and unless there is an historical context I miss, I think I am still in favor of updating it to use the annotation-based programming model which seems more elegant and modern from a programming model perspective, avoid using string based reflection (which we try to really avoid these days) and works out-of-the-box with native. It is ok to document native hints when needed, but I would keep that for use cases where we don't have the choice by design like HTTP client serialization.

@robertmcnees I think that's a great idea to introduce native support in our guides if we can concentrate the native specific instructions in the native section minimized by default to avoid leaking uneeded complexity to regular JVM users.

[robertmcnees]

Thanks @Buzzardo. In addition to making the requested changes in this PR, I also updated this shared file with the same changes. My intent is that the Building the Application section will be standardized across all of our guides. Once this PR is merged, I'll likely take another pass and find some common components to link in the macros repository.

[robertmcnees]

@artembilan @sdeleuze For now, what do you think about removing the instructions for native compilation (and custom hints) entirely from this PR? I can create another Issue in this repository for adding native support. In hindsight, I should have kept this PR more focused to Docker Compose support and changed the Building the Application section in a different PR.

@sdeleuze My end goal is to have all guides have instructions on native support, provided that no custom hints are required. In a more straightforward example, I did a proof of concept with the Getting Started guide that looks to a Shared File.

[sdeleuze]

@robertmcnees Works for me, let's do it in 2 steps.

[artembilan]

Sounds like a plan!
Even if I'm OK reviewing everything in one go.
It really might be better to fulfill an original goal, then go with other improvements in subsequent PRs.
I also won't might to migrate this guide to the @RabbitListener to have native support transparent:

@Target({ ElementType.TYPE, ElementType.METHOD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@MessageMapping
@Documented
@Repeatable(RabbitListeners.class)
public @interface RabbitListener {
...
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Reflective(MessageMappingReflectiveProcessor.class)
public @interface MessageMapping {

Pay attention to that @Reflective in the end.