ポッドキャスト: Andres AlmirayがJReleaserであらゆるソフトウェアをあらゆるOSにリリースする方法について語る

Transcript

Olimpiu Pop: Hello everybody. I'm Olimpiu Pop, an InfoQ editor, and I have in front of me probably one of the, I don't know, veterans in the open source space, especially in the Java ecosystem: Andres Almiray. Andres, thank you for taking the time to talk to us. And if you can, please introduce yourself. You have so many accolades. I don't know which ones to pick, so I'll let you choose the ones that you like.

Andres Almiray: Thank you for having me on the show, Olimpiu. It's a great honour for me. As I said, my name is Andres Almiray, and I'm a Java Champion. This year marks 20 years since I've been actively contributing to open source. It's been quite a ride. As you mentioned, I have been working in Java for a long time. Also known for its work on the Groovy language. There's been a series of projects I've been involved in or worked on over the past 20 years. They range from build tools, application frameworks, build tool plugins and some other things. Every one of those has a little story to it. And I really like the fact that I was able to meet so many different people across time and across different countries, such as yourself, thanks to working with open-source.

Olimpiu Pop: And about those stories, I think I know at least two of them. One of them was related to security in the supply chain space, because it's getting more stringent for everyone, especially with the Cyber Resilience Act here in Europe. People are just discussing how much time they spent on reproducible builds. Hervé Boutemy was discussing some time you spent together while you were gathering the tools you needed in JReleaser. A more common one was from Max Anderson. He was pointing out that JReleaser is one of the better CLI tools in Java because he has a call to arms for everyone in the Java space to do more on CLI tools, especially now with agentic AI and all the other generated stuff. So what's the recipe for success? Because I know that you've been working with JReleaser for a couple of years now, I think so.

JReleaser can release software in any ecosystem, not just Java [02:53]

Andres Almiray: Yes. This year, on April 10th, will mark the fourth anniversary of the release of 1.0.0.

Olimpiu Pop: Oh, wow. Do you still keep the cadence? I know that you are very disciplined with the cadence of JReleaser. Do you still keep it?

Andres Almiray: Yes. We have a two-month release cadence so that people know what's coming up. And we release at the end of the month on the even months. We are recording today, on February 18th. So at the end of February, there will be a release, and the next one will come out by the end of April. We are also very close to starting the roadmap for 2.0, where we expect to make some breaking changes and a few other features that require us to break compatibility. We may start putting out alphas soon, but there will be perhaps a different release cadence going up to 20, and we may keep the current release cabinets for 1.x until we do the final switch.

Olimpiu Pop: Okay. I'm happy to hear that the 2.0 is still on the agenda. I know that one of the things that you had planned there was something special. I don't know if you want to make it public, but at that point, you said it's about to just cut the J out of it because it's not only for the Java ecosystem.

Andres Almiray: Yes. One of the things we mentioned was possibly rebranding the tool. I'm still undecided whether that rebranding should take place. From someone who knows the tool and has used it, they will, of course, know the name. And they may also be aware that you can use it with any source language. We have already made examples for popular languages. Obviously, you're going to find Rust, Go, Python, Perl, C++, C#, Ruby, and so many other strange languages, such as Odin, Nim, not necessarily might call it strange, but it'd be Zig, Swift, and the list goes on and on and on. There is no restriction to use a tool with just Java, just because it has a J in the name. But if someone is new to the Java ecosystem or doesn't know this tool exists, and they try to find a native release tool, they may not find it and think, "Why should I use something that is Java-based to release my Rust project?" It doesn't make sense, right?

Because I want it to be Rust because it's part of my ecosystem, that's the tool chains that I know, right? So that's where rebranding may come in, showing people there is an alternative, even though it's not native to their source ecosystem.

Releasing to any of the major operating systems [05:32]

Olimpiu Pop: That makes sense. I'll look eagerly to see what the outcome of this debate will be and whether we'll have a new tool or an old one that still has a 2.0 after that. But as we discussed before hitting the record button, you mentioned that you hit a plateau in terms of features. And so that points towards a product maturity more or less.

Andres Almiray: It looks like we have reached plateau stability. There are still a few features being added in each release, but not as many as before. So the features in the pipeline do require these breaking changes and breaking compatibility, which we track on the roadmap for 2.0. It may be the case that we are reaching a critical mass of features that say, yes, we had to go to 2.0. We have added additional announcements recently. So when you post a release, you can create an announcement for multiple distribution channels, such as email or a Slack channel. We added the capabilities to announce on LinkedIn and Reddit. And soon, in the next release, we will also support another announcement channel called Twist. We also added the capability to use multiple digital signature algorithms simultaneously.

So in the past, you could only have PGP or a cosign. Now you can have both, depending on the title or artefacts that you want to release. And we also added a third one called MiniSign. And in the early stages of the first releases of the tool, some developers have asked for support for signing with the Windows signing tool, which only runs on Windows platforms, and we would like the tool to be independent of the platform. And some others also ask similar things for running on OSX. So there is a tool called JSign, another open-source Java project you can run on any platform to generate Windows-compatible signatures. This is probably something that we will add before 20. Hopefully, with the April release, we can add features that will allow us to provide any kind of digital signature across all platforms.

Olimpiu Pop: Good luck with all the features. All sounds quite interesting and will definitely be useful. One of the things I know you worked on some time ago was setting up distribution channels across different platforms. Can you figure out a couple of them that people tend to use, or what would be a couple of patterns or lessons learned from what you saw users using?

Andres Almiray: Well, one of the first reasons to build a tool like this was to deploy a JavaFX application in a way that anyone could consume it very easily. So if you use Homebrew, then you will install this JavaFX application using Homebrew. But that requires me to learn a little bit of Ruby and understand the format for creating the manifest for this. And then you'll find people that Homebrew doesn't work on Windows. You need a package manager that is needed to that platform. There are a few options. There is a Scoop, very similar to Homebrew, and, of course, there are Winget and Chocolatey. And the same thing happened. You need to understand how to write the different sections for each one of these different manifest files, whether it's XML, JSON, whatnot, and so many other things that you need to keep track of, that it became so complicated to do these things by hand, and that's why the tool came to be.

So, based on this, we've seen that most people who use the tool to publish to different package managers first choose Homebrew, then go for Winget. Thirdly, they are those that go; whether it's not Winget, they will go without Chocolatey or Scoop for targeting Windows. And then those who would like to create Docker images, whether using Docker, Podman, or Google's Jib, which we also support.

Olimpiu Pop: It seems that people are still using native applications, and Docker definitely has the traction we expected now, given that it has become the norm for most people. But there is still a question. You definitely mentioned that the product is mature. How about architecture, underlying architecture? I know that you put a lot of interest into getting it started nicely. And in one of our first discussions, you were quite happy with what you got started, but definitely, when you're looking at two point something, it's about breaking changes. Are you intending to change something? I'm just thinking that, looking at the data ecosystem from a different perspective, there are a lot of modules you can add depending on what you need. How are you creating that kind of puzzle-like approach?

Andres Almiray: As a matter of fact, as we grew across different versions, we added support for a different set of announcers and packagers that proved more common. So let's say there is Google Chat, Gitter, and I think that Teams also announced that they will natively send user REST APIs to the target services to send information as needed. But as it turns out, all of them can be implemented with a simple webhook, and we do have a generic webhook announcer. So it turns out that some of these explicitly custom-made announcers under the hood now use the generic webhooks, so we have mocked the explicit announcements as deprecated and removed in version 2.0. This is one of the things I want to do: we have already identified features in the tool that are more common and refactored them so we can remove what is explicit.

So these things are shaping a bit of the weight we accumulated as we're putting releases out, making things a little bit slim. That's the case with the things that we would like to break. Correct some of the design choices that we made early on for naming things in the DSL, so that it is more intuitive, so that it conforms to other rules that we discover as we add on more elements to the DSL. All of these things are already being marked as deprecated. So whenever you run the tool with different interfaces, whether it's at grade end or via a command-line tool, if you use a DSL element that's marked for deprecation, you will get a warning in the log so you know it's going away. It tells you when it was deprecated and which release, and it will also tell you that it will eventually be removed in version 2.0.

So if anyone uses the tool and sees any special warnings like this, deprecation warnings, it's a good idea to have a look at the documentation, which tells you what the other way to do things with the DSL will be going forward.

What you should know before adopting JReleaser [12:20]

Olimpiu Pop: Okay. So, to sum it up, on one side you have the feedback you gather from existing users, and the feedback from you and other developers who helped develop JReleaser so far, and you're incorporating all that to make the product more robust and leaner. But as you mentioned previously, when it comes to renaming the product, you're looking at two personas, if you like. One of them is existing customers or users, and the other is new people who would like to adopt it. What are the questions that people should answer when they get started on using JReleaser for their release?

Andres Almiray: Well, it depends on what that person is using when creating a release. So the first question is: are you working on a tool, an application, or any project? It doesn't have to be CLI or desktop. It could be any product you want to tag, create release notes for, and maybe make an announcement when this happens. So the first question is, how are you doing this? Do you already have some level of automation? Are you doing it with a set of batch scripts or with another scripting language? Are you targeting just GitHub? Do you know GitHub Actions, or would you prefer GitLab? So, do you know GitLab CI and how it works? If all these things sound like, "Wait, hold on a second, that is way too much information. I didn't know I have to be an expert or I have to learn so many things in order to do something that just by saying this sounds trivial," but in terms of the case, it isn't.

Then JReleaser may be the tool for you because it simplifies all these things. It follows a convention-over-configuration mechanism, so you can configure as few things as possible and apply as much behaviour as needed. The tool doesn't push you to choose a given path. It's the other way around. You tell the tool exactly what you want. So the next thing is that you already have some sort of release process and some level of automation, but there may be things that are failing, not reproducible, or difficult to automate for one reason or another. And this is a game where the tool can help you; you just pick which items and which parts of the behaviour the tool provides can help you in your release process.

Olimpiu Pop: And because we do live in the age of LLMs and everybody is reviewed for everything, and you did mention a DSL, how easy it would be to just, I don't know, go to one of those LLMs and ask it to help me write something with the DSL? Or is the DSL internal, and I'm asking the wrong question?

Andres Almiray: Actually, the DSL is external, and you can add different formats depending on how you want to consume it. If it's on the CLI, the most common format is YAML, but given that there's a segment of the population who dislike YAML but likes some of the formats, we support TOML as well. If you are using Maven, there is a plugin that you can use the Maven XML DSL to configure the plumbing. If you're using Gradle, we have Gradle plumbing, and it's up to you to decide which DSL or Gradle you want to use, whether it's Groovy, Kotlin, or the declarative Gradle thing that's been coming up lately. So you have at least three choices in Grails. And the last one that we have is also JSON if you want to do it. So there was a time when I considered it might be necessary to add explicit metadata to the tools so that different LLMs could discover the features and provide information for you.

But it looks like, at the very least, cloud is the one that will integrate easily with so many other tools out there, in a way that we don't have to provide an MCP server or additional metadata for it to work. Cloud appears to be smart enough to just be able to parse the information that is coming from the help menu of all the different commands that you can invoke in the CLI and suggest exactly what you can do with it.

Olimpiu Pop: Yes, that's my observation as well. One of the benefits of having these tools is the ability to play with things that normally would take weeks of documentation, stuff like that. For instance, I was never a fan of front-end, and now it's a lot easier to just do this stuff. But what I observed is that, especially with the quick cadence of the JavaScript ecosystem, there is a gap between what information the tool has in comparison with what you currently have after the release, because maybe it's not trained on that, but pointing it to also documentation helps a lot, and that's quite useful.

How to dry-run releases for extra safety [17:09]

Andres Almiray: When you're starting to play with LLMs, you will want to try things out, and you might be nervous to commit and see if they work out. The tool JReleaser allows you to test features in driver mode. So you can run it in a local environment as much as you can. When you're running in drive mode, it means that you will be able to consume information from the outside world, in case it needs to download files or process templates, but it will not push to the remote servers. So it will not create a Git release or accidentally alter any remote files. It will tell you what it's tried to do, but it won't do it, so you're in control. We recently added another mode, and I recall that you mentioned Max's name. This is a feature Max requested; this is the yolo flag.

What happens when you have a confirmation file for a project where you may not necessarily have all the requirements configured, say, for example, you want to deploy certain artefacts to Maven Central, but also want to publish a container image and a Ruby formula for Homebrew, right? If you don't have the secrets required to deploy to Maven Central, attending a release will cause it to fail because information is missing. But if you add the Yolo flag, you can run everything you want. And if something is missing or misconfigured, that whole section will be skipped. You will see a warning in the log file telling you, "Well, we're missing some stuff." It will not tell you the values of the secrets, obviously, but it will tell you we were not able to deploy to Maven Central because we have missing credentials. But instead of failing, it will continue to the next step.

In this case, it will create the package manager files that you want, but you could do it the other way around. So again, you can play with these things. You don't have to configure everything up front to test how the release process will work.

Olimpiu Pop: So it's a tool that you can use to your needs?

Andres Almiray: It's very flexible, yes.

The Commonhaus Foundation - a new home for open-source projects [19:08]

Olimpiu Pop: Thank you. And another project that I think is quite important that you were involved with is the Commonhaus Foundation.

Andres Almiray: Yes. The Commonhaus Foundation is an endeavour that I really enjoy working with. JReleaser is one of the founding projects alongside JBang from Max. I think that we have grown to close to 15 projects now. So we have Quarkus and some projects; other Red Hat projects include WildFly and Infinispan. We also have the first known Java project, SlateDB, which is written in Rust. Although the foundation was originally thought of, oh, let's make this work for Java projects, because most of the people that are associated with the Commonhaus Foundation, we come from the Java ecosystem. We are more than happy to welcome projects that use different languages. It doesn't have to be all Java, and SlateDB proves that. The foundation is also close to its second anniversary, which falls on April 9th.

Olimpiu Pop: You like April Fools projects, right?

Andres Almiray: Yes. It is definitely these two projects that were not released as April Fools'. Oh yes, it's a good time.

Olimpiu Pop: Yes, I knew about Quarkus because whenever I was talking to Red Hatters who moved from Red to Blue in the shift from Red Hat to IBM, everybody kept emphasising it. Yes. But to know that Quarkus is now part of the Commonhaus Foundation, and everybody was quite proud of that work. Congratulations on that. What's on your agenda as a foundation, especially now that we are both based in Europe, Max, as you mentioned, the creator and the keystone of JBang, and also involved with Quarkus, is also European. How do you see the future of open source through the lens of the CommonSource Foundation, especially now that the Cyber Resilience Act is getting into force?

Andres Almiray: So there are three driving tenets of the foundation. This is how we started. The first one is a low-governance model, which means when a project joins, there is no common way to build and do things. The projects that join the foundation are already established. They have a good community around it, and we can certainly help them foster the growth. We have a group called the executive committee, which is comprised of at least two members from each member project, well, the main contributors. This group will not impose a way to build or continue working with that particular project. That's the first thing, low governance. The second one is financial transparency. So if a sponsor joins and decides to sponsor either a foundation or a specific set of projects, they will know where and how the money is being spent. So the foundation does not become a black hole where money just suddenly disappears, and maybe goes into a particular project or not.

So everybody will know how things are going. And the third one is continued succession, which means that if the current set of maintainers for a project decides to move on to a different project or just stop working altogether, the project will eventually suffer. So what we want in the foundation is to provide the minimum structure and the right structure so that existing contributors and maintainers can move into the primary set of maintainers, maintain this continuing association with the project, and thrive. With these things said, the foundation continues to seek sponsors, whether enterprises, companies, or individuals who would like to provide their time, effort, and money to keep all these projects and the foundation growing. And we are also looking to create guidelines and identify common aspects that may affect all projects. What's going to happen with security?

What happens when a CDA is reported? Though we know that the members and maintainers of a particular project know how to handle CVEs and similar issues, there will be continuous communication among members and the executive committee to get this done. Maybe the case that the foundation comes up with not just guidelines, but maybe it's a set of tools, whether CLI, what have you, that could help in a specific project. And this is where we will be able to continue the communication with the other projects and say, "Hey, we have this thing going on. It helped project X. Do you have similar needs?" Well, let's talk and see if this particular set of tools could be added to the way that you think. Or if you are not aware of what's going on with a particular space of security concerns, then we can certainly pass additional documentations or links, but without giving you the idea of this is how you must do things rather than, here's a set of options, you are free to choose what we have already done for others, or based on what we have, you can keep looking into some other alternatives.

How to ask for support from the Commonhaus Foundation for your project [24:11]

Olimpiu Pop: So, as you mentioned, there are two types of sponsors: those providing the time, those getting involved, and companies. Let's say I have an open source project. When should I go to the Commonhaus Foundation for support?

Andres Almiray: So right now, because we are looking for well-established, well-known projects in their respective communities, if your project has a steady set of these issue tickets and you have good standing with your community, then your project will be a very good candidate to join. If this is a pet project or you're just getting started, your project may show promise and join eventually, but it's very likely not the right time right now. But we also have to consider the projects that will be at different stages of development. So if you're just getting started, the Common Files Foundation likely won't be a good fit. If your project is already established and is growing, this will be the ideal time. But if your project is already mature and the community is still somehow engaged, but maintainers no longer have much time.

So your project is now going into maintenance mode and almost going perhaps into zombie mode, then the foundation, they will definitely do a review on a case by case basis, but it's one of the discussions that we have early on in the definition of the foundation, what's going to happen with projects that happen to be in this particular stage where they're perhaps already close to their sunset. One of the things that we would like to have is an idea account like an animal shelter where the maintainers could donate the project to the foundation and there will be a set of people, whether it's a staff or not, that will keep the product alive such that we can find the next set of maintainers that will be willing to take on the project. And if that were not the case, we would just have to declare that the project has to go completely out.

So we'll find a way to make it happen graciously. So, in recap, if your product is fairly new, maybe right now isn't the time to join, but we can keep an eye out for the best possible moment. If you are in your teenage years or close to maturity, that's the right time to do it. And if you're in your twilight years, you still come to us, let's have a conversation and let's see what can happen.

Olimpiu Pop: So definitely useful. And I have a couple of ideas about who can be in that space. So I'll reach out to them, and maybe it's a match, and you'll have another non-Java project joining the Commonhaus Foundation. But let's see, how can people who want to contribute contribute?

Andres Almiray: One of the things we do with our issue tracker is apply different labels, and there's always a little “help-wanted” or “good-first issue”. So these are the ones you can have a look at, and hopefully this is something you can do in just a couple of hours, or maybe a couple of days. Those are the issues that can help you get started with the codebase and fix an issue without having to learn a lot upfront, just to get it done. The other thing that we encourage, at least here in Switzerland, where I'm streaming from, is a series of events called HackerGarten in different cities. It's just a group of people who like to come together and hack for a few hours on any open-source project we think will be fun, and we push our contributions to that project at the end of the session.

So, someone who would like to get started with their first open-source contribution would find events like HackerGarten ideal. Someone who already knows how to do open source but stumbles with Journaliser as a tool that may help them, but they don't yet know how to get it started. Again, this is one particular event that can help. For those who don't have access to a HackerGarten event in person, we have them in Switzerland and in Germany. The other option will always be to reach out to our discussion page. We're currently hosted on GitHub, and start a conversation in case you think, "Well, what about this particular feature? I think about another tool I use at work, but it's not integrated with JReleaser. Wouldn't it be cool if we could do this or that? " We can get into a discussion on whether you would like to provide a patch for it, or if someone else can help you, or if someone else could provide a patch for it.

Olimpiu Pop: So nothing special here. You are welcome to accept contributions, but first label the issues for newcomers. If not, start a discussion; people will find a way to contribute in the end.

Andres Almiray: I think, based on the discussion we had last time, I mentioned that we were close to providing support for SLSA.

Olimpiu Pop: Yes.

Andres Almiray: Well, I haven't written a blog post. I've been very bad at this, but I had to make some sort of announcement that we do provide a native builder for SLSA, at least for the GIFO implementation of SLSA. So if you run your builds, whether on GitHub Public or GitHub Private Enterprise, you can use the GitHub SLSA generator, which requires adding more YAML to your GitHub Actions. But if you happen to use JReleaser, then just using a very specific reusable workflow for SLSA and a YAML file, or what is Maven, is the same; it will make it work. So there's less configuration that you have to do. And the first thing that would prove is that you can do this with Maven projects or Gradle projects, where we expanded additional demos for languages that provide cross-platform compilation. So, Go, Rust, C++, C, JavaScript or TypeScript, whether we use Deno or Bond, I think we also have a demo for Ocalm.

The point is that if SLSA is something you need and interest you, and you don't know how to get started, using this native SLSA builder with your user is very, very easy.

Olimpiu Pop: You definitely make it sound like that. So I'm sure that it's actually ... Thank you for sharing these insights, Andres. And thank you for your time.

Andres Almiray: Thank you so much, Olimpiu. And if anyone is interested in open source, it's very easy to get started. Just open a ticket in the open-source project we're working with. Let the people on the other side of the world know that you're working on it. Maybe you find something that isn't working properly or unexpected, or maybe there's a missing feature. Just open a ticket. You don't have to send a patch. You don't have to send code or test cases to begin with. Don't feel like pressure to do so upfront. Just start a conversation and see where things go.

Olimpiu Pop: Okay. So guys, just do it.

Andres Almiray: Yes.

Mentioned:

Commonhaus Foundation

JReleaser

About the Author

Andres Almiray

Andres is a Java/Groovy developer and a Java Champion with more than 2 decades of experience in software design and development. He has been involved in web and desktop application development since the early days of Java. Andres is a true believer in open source and has participated on popular projects like Groovy, Griffon, and DbUnit, as well as starting his own projects. Founding member of the Griffon framework and Hackergarten community event. You can find him on twitter too as @aalmiray. He likes to spend time with his beloved wife, Ixchel, when not hacking around.

Show moreShow less

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via

SoundCloud,

Apple Podcasts,

Spotify,

Overcast

and YouTube.

From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.