Arconia for Spring Boot: Dev Services, Automated Migrations, and Seamless Workflows by Thomas Vitale

This talk celebrates the 22nd anniversary of the Spring Framework and reflects on its evolution, particularly with the introduction of Spring Boot, which simplifies Java application development. The speaker discusses his journey from learning Spring MVC to discovering Spring Boot's features, such as embedded web servers and auto-configuration that allow developers to focus on business logic rather than boilerplate code. He then introduces Arconia, an open-source project aimed at improving the developer experience in building Spring applications, especially in managing complexity and fostering best practices. The speaker demonstrates various features of Arconia, including dev services for managing dependencies and observability tools, showcasing its usability for creating AI-integrated applications. To conclude, he invites the audience to engage with the Arconia project and shares insights into the open-source community.

[music] >> Can you believe this year we are celebrating the 22nd anniversary of the Spring Framework? That was a game-changer in the Java ecosystem. And I still remember when I first learned about the Spring Framework. I was at the university. I was attending this course. Uh the first few classes were about learning the basics. Spring Framework, Spring Data, Spring Security. And I was immediately hooked. I started

spending quite some time after class checking the documentation from the Spring project. And I was so amazed by how good that documentation is. It's not to take for granted. Like the Spring documentation is phenomenal. It's so detailed. It's so comprehensive. So I really enjoyed it. Spent quite some time building my application for the class. Uh I looked a lot into how to set up Spring MVC, how

to deploy that on external Tomcat server, how to configure persistence, Hibernate, Entity Manager, security. I was really proud of that code. And then I go to class next time and the professor introduced us to Spring Boot. And that changed everything. Because all of a sudden I realized all the code, or most of it, that I wrote up to that point, I could delete it all. So I

was a bit upset at the beginning. Because I spent quite some time defining the list of all the dependencies I need in my application. Uh but then Spring Boot came with the starter dependencies. That's incredible. I just add the Spring Boot starter web dependency and I get everything I need to build a web So no more dependency hell. All right. But still, I quite spent some time

crafting all the beans for Entity Manager, data source. That's still useful, right? Well, we got auto configuration. I don't have to spend time writing that. So I could delete all that code as well. Fine. What else? Did I write anything useful? I had all my workflow set up to deploy my application locally on a web server. Well, it turned out Spring Boot came with an embedded web

server. You could build a standalone application. But more than that, because you get a production ready foundation to build your application. Out of the box, Spring Boot comes with production ready configuration. So you're ready to focus on the business logic. And that was that was amazing. That was 2017 and over the past few years, lots of things changed in the way we build software. For example, we

focused more and more on distributed systems. And not just because of microservices, but these days we talk even more about these kind of systems because we want to integrate different agentic applications. We are talking about agents, sub agents, multi-agent MCP servers. It's all about distributed We established some cloud-native patterns for designing and architecting applications that can be scalable, resilient, secure. And most recently we introduced generative AI

tools in our development toolkit. So our development workflow changed. So since we started from a foundation that was production ready, now with all this complexity, we have to think about the developer experience. Because we're adding lots of complexity and cognitive load. So I started looking into my way of working with Spring Boot building applications and I noticed some friction points, some gaps. And then looking around at

the broader Java community, looking at how other projects are solving these problems, I realized they are common problems. Even beyond that, even just by looking at the cloud-native community, there are some problems that really pop up across different tech stacks. So I started tackling some of them and decided to consolidate quite a few of them into a shared library, an open-source project, so that I could share

it with people. And that project is Arcona. And I'm really, really excited to talk about Arcona here. This is the first time I'm presenting about it and it's quite fitting that it's here at Spring I/O because the original idea actually came here a couple of years ago after my presentation about multi-tenancy. I'm Thomas Vitale. I work at Systematic, a Danish software company. I'm really passionate about anything

Java and cloud-native related. very active in the open-source space and wrote a book about some of these topics. I have some digital copies to give away for free. So if you're interested, just reach out to me later. But let's get started and let's build an application, shall we? So I go to start.spring.io. Let me make that bigger. So we start with a simple web application. I'm going

to add Spring Web and Spring Boot. No, what's that? I don't want to print it. Uh and Spring Boot Actuator. So we get a nice production ready foundation. I have the project open. I can run it from the main method just like any Java application. Perfect. It's running port 8080. Uh let's go and see what's going on there. Okay, white label error page. How many of you

have seen this page before? This is a very common one, right? And sometimes it's confusing. In this case it makes sense. I haven't defined any endpoint. So it says, "Hey, 404 not found." It makes sense. But as I also teach Java and Spring Boot to new people, then I realized this can be confusing because they bootstrap any application, they get an error and they're confused about why

it doesn't work out of the box. But it actually makes sense. Also, we notice how it's production ready by default because it doesn't leak any internal details, a stack trace. So it's really tailored for production. But they do have some endpoints because we added Spring Boot Actuator. So let's have a look at that. I don't get much out of the box. Once again, production ready by default.

So I only have the health endpoints. But during development, I really like having all these endpoints available. So let me go ahead and enable those. I go in the application property file. Uh let's zoom in. So I can say management.endpoint.web.exposure.include. Let's include everything. Now this is one of the worst thing you can do in Spring Boot. I just enabled all the endpoints in the main property file.

So I basically voided the production readiness that Spring Boot gave us. Because now if I forget to override this property in production, I'm going to have a problem. And we heard so many cases of systems being hacked into through Actuator endpoints. And there's always someone blaming Actuator that is not secure, there's many exploits available. But actually it's a misconfiguration and it's only our fault if we do

something like this, right? Because Actuator, even the configuration out of the box in Spring Boot, it's secure because it doesn't expose anything else than the health endpoint. So a common pattern we have in Spring Boot is defining some profiles to isolate configuration we use during development. So I can create an application-dev.yaml file in here. And it's here that I'm going to add that Let me copy that

in here. Well, I should remove it. Cool. Now I need a way to enable this dev profile. Now I've seen projects doing spring.profiles.active=dev I don't think that solves the problem. Because once again, we risk to enable this in production. So we need to do it differently. Uh this is a Gradle project, so it may be a slightly different, but what we need to do here uh is

configuring the bootRun task from Spring Like this. To enable the dev profile. So it's only enabled when I run it locally. So I can define a system property. Uh it's called spring.profiles.active. And the value is dev. All right. Let's see if it works. Now run the application. Spring Boot conveniently logs that yes, the dev profile is active. Cool. I don't want to run it from the CLI.

It's very convenient to use IntelliJ. So let me switch to that. And run it from but there's a problem. Or is there? I think I spoiled the ending. Oh no. Yes. That's not supposed to be there. So let me run the application once again. >> [snorts] >> And it's still the default profile. That's because IntelliJ doesn't use the configuration you have for Gradle in the build.gradle file,

but instead we have to change the configuration in IntelliJ directly. So I have to enable the profile here. Okay. Now if I run it again, I get the Similar issue for testing. It's a common pattern to have test specific configuration. Maybe I want to enable logging for all web requests. That might give us some extra information. But then I need to remember to configure that profile. So

if you go down here, we can do the same for the test task and enable the test profile. Now I do this in all applications basically. It's very common both because it's convenient to have a way to define dev and test only configuration, but also because I want to avoid problems in including some default configuration in the main production file that risk to be enabled in production.

with Arcona, the first feature I want to show is the detection of the bootstrap mode. So what is the runtime environment of the application? And we can identify three main modes. The dev mode when we run the application in the development environment. There's the test mode when we run integration and slice test. And the prod mode. That's the default, what we get out of the box already

now. Now by having a way to detect the bootstrap mode, we can start doing lots of interesting things. For example, among the other things, we can automatically enable these profiles for dev and test out of the box using auto configuration Spring Boot style. So now I'm going to add back again the Arconia that brings the core features of Arconia and I can remove all the extra configuration

I put here, so I don't need to customize the boot run task anymore, not even the test task. I can also remove the extra config in IntelliJ because now out of the box when I run the application, I will get the dev and test profiles enabled for me. That's quite convenient. Out of the box, I don't have to configure it. However, some of you might be accustomed

to a different naming style. I know of some teams that instead of using the dev profile, they use local profile. So what to do in that case? Well, you have full power to customize this. So in the property, I can specify that the dev the profile I want to use in dev mode is named local and then Arconia takes care of that. Now that we have this

foundation in order to distinguish between when we're running in development mode and in test we can proceed and do something a little bit more interesting. In particular, I want to add data persistence. So if we go back to the Spring Initializr, I can add Spring Data JDBC. I'm going to add Postgres and then Flyway. I want to use it to version control my database schemas. And then

I need to add a dependency here, too. Let me do that here. Spring Data JDBC, Flyway, and Postgres. Perfect. Now let's create our domain model. We can define a record named book. The primary key will be of type long and then we have the title. So this is the Spring Data ID. Perfect. And then we need an interface to access that. Let me get rid of it.

Yes, we want a book repository interface that extends from list prod repository for object books of with the ID of type long. Now let me refresh the Gradle dependencies. So we're building data persistence in an application. That's a very common thing that we do. And what I can do is now defining the schema. So that Flyway will automatically initialize my book table in Postgres like that. Um

we have Okay. So now we create a table. At startup time, Spring would quite conveniently trigger Flyway, so it will execute these migrations, but there's a problem. We don't have a database. So what do we do now? I asked through the conference app what type of systems you're using in order to spin up these kind of dependencies and many of you answered Docker Compose. So that's definitely

an option. So I could add a Docker Compose here define a Postgres container. That works. I can even use the Spring Boot Docker Compose support. I have two main challenges with this one. One is that I have to maintain this code now and the other one is that there is a bit of trouble when I want to reuse the same configuration for testing because for testing I

really like using test containers. It gives more flexibility when running automated test. So can we use test containers for both? Let's try. I'll remove Docker Compose and I'll add the test containers dependency from Spring Boot. Test containers. Like that. So we get the Spring Boot support for test containers and the Postgres module for test containers. Now this one only lives in the test class path. So I

have to go there and define some configuration under the test class path. Let's call it test config. Like this. This will be a test there it is. We can define it as a bean. Quite conveniently, Spring Boot will find it and start the container for me like this. But I also need an extra notation, service connection, and by doing that, Spring Boot will automatically determine the connection

details from the Postgres container and configure my application to call that container. That means I don't have to go in here and define any data source property. This is really, really convenient. I really love this feature available since Spring Boot 3.1. Now the problem is this lives in the test class path. So if I run my application, it will not be picked up. So I need a

workaround for that. So I need to define a separate entry point into my application in the test class path. Let's call it test application. we have test main. So what we do here is extending our main application class, the one that is annotated at Spring Boot application, and we are extending that with test containers configuration. And now we need to run the application from the test class

path. So I cannot use the normal main task. So I have to run it from I can do it from the IDE, so it will get the separate entry point and it works. So it's starting test containers. Or I can use it from the terminal, but I have to remember that boot run will not work anymore. I need to change the task in boot test run. Then

it will run the app Okay. Now this works, but I can't help thinking about that experience I had the first time I learned about Spring Boot where I had all these beans defined in my application, a data source bean, entity manager bean from Hibernate, and then Spring Boot offered auto configuration and I could remove all that code. Can we do that here as well? Can we remove

this entire configuration and get it out of the box for free? Maybe even with the custom configuration properties that I can use to tailor the behavior. Let's see. Let's delete the If I want to use test containers in test, I need to import that configuration here explicitly. auto configuration for all the other types of test usually comes out of the box. So once again, can I get

it auto configured for me? And how about this entry point? I really liked when we switched to embedded servers with Tomcat because I didn't have to worry about the server. I the application through the main Java method, but now I have a separate way of doing it. So can we stick with the normal way of running a Java application? If I delete this and final thing, dependencies.

That was one of the great things with Spring Boot starter dependencies. I don't have to know about all the many dependencies I need for a certain purpose. Here I have two dependencies. Can we bring it down to one? Maybe just if I want this Postgres service. Now I removed all the code and configuration I've added up to this What I'm going to do is add one single

dependency now from Arconia. It's available only for test and development. So you can see here it will not be packaged with the final application that you deploy to production. And what happens now if I refresh Gradle and start the app from the main method? Let's give it a try. Let's check the logs. It's starting the Postgres container. The application is fully initialized. So now all of that

is auto configured for me and I can also still running the application in the normal way that I usually use. And for testing, that's the same. I don't have to import anything manually. I run the test and automatically I get the Postgres SQL All right. This is one of the main features of Arconia. It's called dev services and is built on top of all the common patterns

we already use everywhere in Spring Boot, auto configuration, starter dependencies, configuration properties, and it comes from this idea that originally was introduced in the Quarkus project where they have dev services as a first class citizen. So now we have similar way to have that kind of functionality in Spring as well. So it's zero code, zero configuration. I add one dependency and then I can run the application

in the normal way. This for me is a really better developer experience because I don't have to copy and paste that code everywhere. It's true I don't have to write it from scratch. From the Spring Initializr, I can even generate it. I've been having sort of a mantra for many years. The best code is the one you don't have to write. But then I realized it was

really wrong because you can generate code. Even before AI, you can generate code in many different ways, right? But even if you generate it and it ends up in your code base, then you have to maintain it. So I switched my mantra to the best code is the one you don't have to maintain. And then I was proven wrong again because hey, I can use an agent,

can do all the maintenance for me. I don't even need to look at the code. So I changed it one more time and I hope it will stick. So I challenge you all to find the flaw in this one. The best code is the one you're not responsible for. I hope we can all agree with that. Let's see for how long this will be true. But this

is all to say that even if we can generate code, if we have a library that can provide certain things out of the box, we're not responsible for for that because it's the library itself that needs to take care of the maintenance. So with the dev services, we have lots of different possibilities. Arconia provides many modules, some of them contributed by the community. And I want to

show one specific example regarding observability. That is something I always add to any application as well, because to be I want to have some observability. And I have an open telemetry support in Arcona. It's built on the great Micrometer support in Spring Boot. I really like Micrometer, especially the observation API that you can use to instrument your code once, and from there you can export it in

different ways. It's amazing. I combine that with full support for Open Telemetry API. There are some gaps right now in Spring Boot regarding support for the metrics API and the Open Telemetry environment specification. So, this was a way to fill those gaps and have full support for Open Telemetry while getting all the benefits from Micrometer. And I also wanted to have a unified configuration. So, I configure

an observability backend once and use it across different signals, logs, metrics, traces, profiles. So, let's see how that looks. I go back to my application and add some Open Telemetry dependencies. I have the Spring Boot starter for the Arcona Open Telemetry project. And then I have a Dev Services for Grafana platform based on Open Telemetry. It's called LGTM, Loki Grafana Tempo Mimir. So, let me run the

application now. Once again, I'm not configuring anything because by default logs, metrics, and traces are both enabled and exported to the backend. And Grafana, we can see that is started. Oh, I need to refresh the Gradle dependency. Let's do that. So, Grafana will be started and in the logs we should be seeing the URL where Grafana is accessible. That's a lot of text. And we're going to

fix that soon. So, I click on this link. And we have Grafana here, where I can check, for example, the logs from my application here. Now, this is all out of the box, but we are solving some issues with Dev Services, but I think we're introducing some other issues. Because now the more we add all these Dev Services, the more containers we'll have running locally for all

of these services, the trigger becomes to keep track of all of them. So, if something fails, you need to go and check logs from each container individually, or you need to browse through all this wall of text looking for endpoints to access the UIs from different tools. So, a way to uh little bit mitigated problem for me was to add a Dev Services Actuator endpoint. So, at

least from here we can get information about all the services that are running. So, we have Postgres, we have Grafana, but I think that's still not enough. looking at um Here, let me add one more dependency. Looking at different projects out there that have some sort of development console that is only available during development to support feature development or bug fixing, I was really impressed by the

Dev UI in Quarkus that provides lots of convenient tools. So, I figured how would that look in a Spring Boot? I bet it will be useful. And so, I implemented that. This is a preview. Nobody saw this before you. Let me run the application. So, it's a snapshot, so it's everything I'm showing here it's already published on GitHub. This one not yet. It's getting there. So, now

I run the application. And maybe a little bit less zoom. So, we get now a Dev UI. A Dev UI that gives us insights into all the different dependencies I have in my application. For example, I can see the Arcona Open I can see the logs, metrics, and traces are all enabled and being exported. That's really nice. I can see the bootstrap mode is dev and the

dev profile and the test profiles, how they are configured. I can see that at a glance. We've been working with Flyway, so I can inspect the migrations in here very easily. I have Grafana, so I have a Grafana Dev Service, so from here I can directly access the UI. I don't have to look for the port number in the logs anymore. And I can also get extra

insights into Spring Boot itself. For example, we're using Spring Data, and I can browse all the different repositories and entities I have registered in my system. Or maybe I need to debug some auto configuration, something is not being configured properly. I can check all the auto configurations that are enabled and the ones that are not enabled. So, I can more easily find some bugs. Or maybe I

want to debug that problem we saw earlier that we didn't have any root endpoint. So, I can check all the maps in request mappings that are registered in Spring Boot. And we can see here that all the mappings come from the framework. There's nothing coming from the application because after I don't know, half an hour still I haven't implemented a single endpoint. Wow, that's a record. We

should fix that soon. One last thing, we have the Dev so we can see information about them and even check the logs. So, if something is failing, I can check the logs from here One more thing actually. Like lots of this information you can extract it in different ways from Spring Boot, maybe through Actuator endpoints or by enabling extra logging in the application, but there's something that

is not available out of the box. Through Actuator we have access to two endpoints that are quite useful. One is config props that gives you information about all the configuration properties registered in the system and the endpoint that gives you access to all the things that are registered with the Spring environment. Now, the problem with this is that you don't see the effective configuration used by the

You can see all the different configuration sources, but then Spring Boot has this nice hierarchy that lets you override values based on a well-defined list of priorities. So, in the Dev UI I wanted to have a way to know exactly what's the value that right now the application is seeing live. So, in this page we see the effective configuration. So, for example, we have a bunch of

properties here coming from Dev Services that are default properties. So, I know that they are defined by the library or the framework, but I can also see the ones coming from the environment. So, for example, I have customized the Spring application name property with the name of my application, which is quite conveniently and creatively called demo. And I think that's it. I think we can explore this

a bit more with something a little bit more complicated. So far we have data persistence, we have We got to add some AI, right? So, I want to create a project now that has all of these that we have just seen, and on top of that, let's add some AI capabilities. Now, I'm going to bootstrap the project in a different way now and introduce something else, the

Arcona CLI. The Arcona CLI provides lots of different commands. I'm going to show a few of them now, and I start with the Arcona create. This will let me create a Let's call it AI demo, and let's do it here. >> AI demo. And I can point to a template. So, I can base my project on an existing template that I curated. The template is server AI

rug. I'll show you in a second where that comes from. We can define more configuration like the group ID or the package name, but yeah. Let's leave it at that. Now, what happens here? In the context of an organization, you start defining some conventions that you want to apply to all the applications you create. You want to start You don't want to start from scratch every time.

So, it's useful to create some templates, some blueprints that you can use, so you can have a blueprint for an AI application, one for a full stack web application with maybe a Vadin UI, another one for REST services. It's very convenient, and centrally you can manage these templates and use it everywhere across the organization whenever you need to create that type of project. With Arcona, I created

a way to manage a catalog of templates. So, we can check here. We a list of templates. With the Arcona project, I have defined some templates that I commonly use for building application. For example, this one is for building AI application. You can also define your own. So, there's all the facilities to create your own collection and publish it and add it. But for now, I want

to show you that the project I created it's being created and is fully customized using Open Rewrite. There's an Open Rewrite recipe under the hood that customized the application name, the group ID, the package name, all those things. So, let me open the let's quickly set up a rug workflow. So, we're going to have an injection pipeline. So, I want to ask questions about some stories with

the AI model. So, this one will be a Spring component. Let me zoom in a bit. And we're going to create an injection pipeline. So, we need to prepare data to be used with an AI We have a bunch of imports here. Yes, yes. Let's import everything. So, what I'm doing here, I'm using two or actually three main project. So, the first project I'm using is called

Docling. Docling is an open source project that lets you prepare any kind of document, both textual, but also audio, video, images into a unified format that can be fed into an AI model. It's open source, it runs locally, so it's also secure and private from that point of view. And then I have a vector store. This comes from Spring AI. That's where I push all the data

that I want to make available to AI and then I'm using Job Runner in order to ingest all this data. So, I can define a job. I can trigger it in different way, for example, as a recurring job. Now, once I have all this data, we can see here we are ingesting two documents I have locally, a markdown file and a PDF file. I add them to

the vector store. Cool. Let's add the first endpoint of the day, finally. This will be for RAG. So, we're going to have a RAG endpoint using the chat client from Spring AI, of course. Uh here I'm using uh Ollama locally. So, all of this is running locally. There's no cloud services uh involved. Uh that's a lot of imports. Okay, so what's happening here? Uh I'm using the

chat client. I'm using the Retrieval Augmentation Advisor. This is an advanced way in Spring AI to build a RAG workflows. There are many modules you can put together in a workflow. This is the very basic because as a minimum at the minimum we need to have a way to retrieve all this data from somewhere and we are retrieving that from a vector store. That's what we are

doing. And then we send the question to the model. So, finally we can start the And we can see how the Dev UI can actually help us even more in this case. So, I have it open here. Perfect. So, now we can notice a few more things. First of all, we have Duckling. Uh Duckling uh is now available natively in Spring Boot through the Arconia Duckling project

that also integrates with Spring AI. I'm actually part I'm one of the maintainers of the Duckling Java project. So, we were working on Duckling support across different frameworks in Spring and Quarkus. So, we joined forces and we created an official Duckling Java project under the Duckling organization. So, that's an open source project on which the Arconia Duckling integration is now built. we have also the UI from

Duckling. If you want to try it out and convert different documents, you can also do it conveniently from here. We have Job Runner. Uh Job Runner comes with a nice dashboard as well and we can see that we have some recurring jobs like the Duckling ingestion pipeline. So, let me trigger that. Otherwise, we have to wait 13 hours for that to trigger. Uh and at this point,

I think that we can also look at the Spring AI support. So, we have PG Vector. Now, interesting thing. I'm using the Dev Service for Postgres and by default it provides a Postgres service. But if it detects that you have PG Vector from Spring AI in the classpath, it will change the default image name. So, if you go and check the image is not anymore a Postgres

image, but it's a PG Vector image, which is Postgres plus an extension to make it support vector data that we need for AI. So, I didn't have to configure that. Uh final thing, we have the Spring AI Ollama support. So, we can even list different models. In the future, I hope we can have a chatbot in here where you can try out the different models uh already

here before you select one for Uh let's see if it works at this point. it was uh RAG and we send a No, we send a question like this. So, there's a story about a character named Yorek that dreams to see the northern lights. Uh what is Yorek's dream? Yes, northern lights in the uh North Pole. So, let's see if we get the correct answer. Now, I'm

running Ollama locally and this is quite interesting because I have a Dev Service for Ollama, but that is not triggered because it detects that I have it available natively. And native Ollama runs uh better than containerized Ollama. So, I still have an application that can run everywhere. Even if you don't have Ollama, the Dev Services will provide one for you. But if you do have one, it

will try to use it because it's more performant. Uh I think we are are done here. The last thing is observability. In this case, I hooked up a dedicated AI observability platform called Phoenix and we can check here very nicely what's happening under the hood. So, I just used the chat client. I used the Retrieval Augmentation Advisor and I can see that I called Ollama locally using

a model Ministral. That's one of the open source models that comes from Mistral. So, I can see all the prompt, all the retrieved context that was added to my prompt and Spring AI managed under the hood and I can see the output. Uh I think we're ready for production at this point. So, what do we do is maybe start building and testing the application. The Arconia CLI

also provides some convenient methods for because I find it quite hard. Like I work across lots of different projects, some using Gradle, some using Maven, some on Mac, some on Linux, some on Windows. And there are also differences if you're running Windows from a PowerShell or from a command prompt. So, there are many commands that we have to run. Uh so, with Arconia, I wanted to provide

a nicer experience so I can just run Arconia build, test, or dev and I get the build tool auto detected, the operating system auto detected. So, I don't have to worry about that. I can just open a Java project and run this command. And this came from my let's say jealousy of the Go ecosystem. I also built some Go application and they have very nicely this experience

where you can just say go build, go test, go run out of the box. We don't have that experience in Java, unfortunately. So, I was trying to get closer to that kind of experience. Now, we can build the application and package it as a container image. There's also a command in the Arconia CLI for that, building multi-architecture images so it can run both on my Apple Silicon

computer and on a Windows computer running Intel. Uh doing this uh is based on the Buildpacks support in Spring Boot. If you had to do it directly, you need to build each image variant individually and then you have to build a Docker manifest. So, that's quite convoluted and that's additional cognitive load. You need to learn about OCI and what's a Docker manifest. So, I tried to simplify

that approach also for me because I do this a lot. So, now in my pipeline, for example, on GitHub Actions, I can run this command instead of orchestrating the different variances for the platforms. Uh super. Now, we're in production and of course we need to keep our software up to date. I have here a Spring Pet Clinic project. I checked out the last version that was still

using Spring Boot 3.5. I can show you that. So, it's using Spring Boot 3.5.6. That's quite an old version. How do we upgrade it to Spring Boot 4? Well, in Arconia Arconia CLI, I have also taken care of that. So, we can Once the project is here, I can say Arconia update Spring Boot to version 4.0.0 And under the hood, this is using Open Rewrite support, Open

Rewrite Gradle or Maven plugin to run recipes that are part of the Arconia project to upgrade to Spring Boot 4. Now, there very different things that are available in this area. So, there's the Arconia update command that gives you these convenient ways to upgrade Arconia itself. So, whenever there's a new version of Arconia, you can automatically upgrade your apps. So, we take care in the these recipes

of all the breaking changes if there are any. Spring Boot, Spring AI, Gradle, Maven, but you can also get access to the full Open Rewrite catalog directly from the Arconia Rewrite command. So, you can run any kind of Open Rewrite recipes. let's see. Uh the command is still running. Let's give it a minute. In the meantime, I I think in here we have our demo application. So,

here I want to show you that with rewrite, we can discover some recipe. Out of the box, Arconia CLI relies on the open source recipes from Arconia and Open Rewrite project. So, we can see there's lots of different recipes, like many of them about Spring Boot 4. Um I can choose one of them and run it. Uh but the project is done. Let's see if it's really

correct. So, we have the build.gradle file. Okay, it was upgraded version 4.0.5. We have all the new dependencies updated. Uh we have all the new packages. You know, it was really great to have this modularization effort in Spring Boot 4. So, all those endpoints are taken care of. We also need some extra notations in some tests, I believe. Let's see. For example, here. So, you need to

auto configure explicitly the REST client you're using. That's all good. But now you might be wondering, why do I have to do all these things if I can ask an agent to do that? I show how to create a project. Why not asking an agent to create a project from scratch? I'm showing how to upgrade a project. Why not asking an agent to do that? Well, the

problem is in the outcome that we are expecting, especially if you're working in an enterprise setting and we go to production in a safe, reliable, reproducible way, we cannot just start from scratch every time using a model. So, you might use an agent, for example, to build your templates. So, in your organization, you can have a set of You can use an agent to help you build

those templates, but then they are maintained separately. And then we might ask an agent to build a new project starting from one of those templates. Or perhaps in this case for upgrades, we can ask the agent to rely on some of these recipes to upgrade the project. It's more reliable, it's deterministic, and it's reproducible. So, we need a way though to teach the agent about all these

tools. So, Arconia CLI is very, very new, so of course the agent doesn't know about it. Now, how do we tell the agent about all of this? Uh right now, the most suitable way of doing that is through something called agent skills. So, it's a way to provide uh some dedicated prompts to the agent that are activated only when needed. Um of course, just like everything else

in agent world, it's all markdown file. So, what we can do here is using one last command I want to show you from Arconia. It's called Arconia skills. With Arconia skills, just like with templates, you can build your collection of skills. So, I have a collection list command. So, I have defined in Arconia different skills that teach the agent how to do these operations I just show

automatically. For example, there's a Spring Boot upgrade um skill. So, what I can do now is say Arconia skills add. Uh then I need to give it a name. So, I'm referring to uh the skill I already have available in the catalog in here. And I think that's it. I can also specify some agents have dedicated configuration. So, I can specify that. For example, in this case,

uh I'm using this one. It's a Mistral vibe. It comes from uh yeah, Mistral. Mistral AI is a European company building lots of different things in the AI space, including lots of open source models that I'm running locally in And if we go and look at that, so we got some new files. We got a skills.json This is a manifest where we uh I'm trying to zoom

in where we can define all the skills that we add to a project. We really need this capability because we cannot just download random markdown file, copying and pasting everywhere. Like, we want to adopt good dependency management practices. And also, it considers supply chain security. So, we want to ensure the provenance of all these skills, right? So, we publish them as OCI artifacts just like the templates

I showed earlier. And even if I delete the folders here, I get an agents folder with the skill. It's a markdown file. I can remove that. So, I don't need to include it. I can add it as a git ignore, for example. I don't have to push it in the in the code base because just like maybe in Java, if you run npm install, here I can

run Arconia skills install, and then it will install all the skills that are listed in that manifest. So, at this point, what I can do is uh an agentic session with Mistral vibe. Now, Mistral knows about my Arconia CLI, so I can ask something like update this Spring Boot project to the latest Gradle version. And if I configured it correctly, it should find that skill. Um let's

see. No, okay. Let's go there again. So, we have the Spring Boot clean All right. So, update this Spring Boot Uh we have the skills there. We also have the special configuration for vibe. In theory, it's working. I'll look into that later, but for now I want to show you that all of this infrastructure here is not something that just works in Arconia. It's something that I

hope can across different tech stacks. I wrote a blog post recently about how to manage agent skills as OCI artifacts, and I submitted I started a discussion in the agent skills project to add this part to the specification. Because the specification is standard, all the agents support it. However, we don't have a common way to package, distribute, and manage the skills. So, everyone is inventing their own

way. So, there's no interoperability, and we need interoperability. And just to prove that this works across ecosystem, Mauricio Salatino implemented the specification in Go. So, he built a CLI in Go with the same functionality provided by Arconia, all based on a common specification. So, we hope this will move forward and eventually will be part of the agent skills specification. I mean, I kind of want to try

last time. Third time's the charm, right? Um update to the latest uh Gradle version this Spring Boot project. I mean, at this point, it's one command with the Arconia CLI, and then I'm spending all this time uh just uh yeah, okay. Fine. I'm faster than you. Okay. [snorts] I've upgraded Gradle. See, we don't need agents. So, what's next? Well, Arconia is not uh it has not reached

the point of the 1.0 release. I hope it will very, very soon, within this spring. But, I really encourage if you're interested in the project to reach out, to provide feedback. We have already several people that have been contributing to the project either via pull request or by opening discussions, reaching out for feedback, providing inputs into the documentation that maybe was lacking. So, any kind of contribution

is greatly appreciated. So, thank you for that. And at this point, I'm done. Everything you've seen, it's all on GitHub. Again, Arconia is a an open source project, so you can find it all on GitHub. The only thing that is missing is the dev UI. That will come very soon in the project. I mentioned lots of different tools today, but one in particular, Open Rewrite, has a

workshop that will start soon after this session. Here at Spring I/O, so feel free to check it out if you're interested in that. Uh at this point, I thank you all for coming. I have some Arconia stickers and some very limited t-shirts. So, if you're interested, come talk to me. So, have a great rest of the day. Thank you all. >> [applause]