Episode 794 transcript

FLOSS-794

Jonathan: Hey, this week, Katherine joins me and we talked with Andres Almeray about JReleaser. It's the way to automate your releases and kind of make them self documenting. It's more than just Java and it's more than just releases for that matter. You don't want to miss it. So stay tuned. It's this Floss Weekly episode 794 recorded July 30th.

Release them all with JReleaser.

Hey folks, it is time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett. And we have a real treat today. I'm kind of getting some payback for the last several years. Well, first off, Katherine joins me today, Katherine Druckmann as, as co host.

Welcome Katherine.

Katherine: Ah, thank you. Thanks for having me again.

Jonathan: Yes. And so Katherine, you're, you're, we were talking before the show. You're about halfway responsible for bringing our guest on today. Because you, you, you introduced me to Lori and then Lori's like, Oh, by the way, I know this guy that does the, the J releaser.

It's a, it's a Java program. And I'm like, Oh, Java, but for those that have been watching the show for a while, no, I'm not a huge Java fan. Now, to be fair, this is probably because I tried to do stuff in Java as a very, very young developer. And the frustrations that I was feeling with simply, let's be honest, not being very good at writing code at that point in my life, I sort of associate with Java.

And so. Maybe it's not Java, maybe it's just me, but All the same. I, I still, every time somebody tells me about a job or, or, you know, ask somebody what, what language is such and such written. And please tell me it's not in Java. So this week's a Java pro project. Next week's a Java project. Maybe we're going to just burn my distaste for Java out.

Maybe, maybe yeah. Revenge of the job. That's a good show title. Maybe we'll go with that. But for a guest today, we have a Andres Alomare. He will tell me if I mispronounce that, I'm sure. And he is a Java developer. And he is, well, he does a lot of things. He is a developer, developer advocate for the database group at Oracle.

Interesting. But he is also involved in JReleaser. Built in Java for Java. And this is, this is all about, it's about pushing releases. Like, so it's, it's part of your which could you call that? Maybe it fits into a continuous integration pipeline, but it, at the very least, it's a part of your release pipeline and that's a difficult problem to work out sometimes.

I think, I think Java has maybe some extra wrinkles with doing releases that other languages don't. Don't it's at least a little different from doing C projects. So let's let's bring him on though Let's not waste any more time And once I get him unmuted here

Andres: Andres, welcome to the show Hi hello Jonathan, hello Katherine, and for having me today.

Jonathan: Yes, yes, I appreciate you being here. Appreciate you being patient as we worked through a few uncharacteristic technical issues at the beginning of the show. Had some gremlins in our system today, but hopefully those are behind us.

Katherine: So it's funny when the nerds can't make it work. It's like, what hope for what hope is there for humanity?

Jonathan: Yeah. Yeah. Okay. So J releaser, give us kind of the, as we say here, the 30, 000 foot view, like what, what does this tool do? What do people use it for? What, what problem does it solve?

Andres: So the problem that it solves is a releasing any kind of projects into any given targets that you may have, for example, the most basic way is create a GitHub release page and uploads any binary assets the project may have as release assets.

And post announcements to different announce communication channels, where it may be X, Twitter, Mastodon, Slack Mattermost, I mean, email, there are many, right? If you happen to be built an let's say a macOS app or a command line tool that you would like to see installed using popular package managers.

Such as homebrew, macports, scoop, winget, all these things. Then the tool will also generate the required manifest files and create additional git repositories if needed to push out those files so that the package managers will have a much better time and you as a final consumer will just simply have to do brew install my app and then you're done.

Jonathan: All right. Brilliant. Huh. So, it's, it's aware of all of these different places you might push to. Now, is, is JReleaser aware of things like, say, a let's say GitHub Actions? So I know a lot of projects have some of this automated where, you know, you have a github action that you go and you run it manually and it will, it'll bump your version number and run your, your final tests and then produce your release.

So can, can you set jreleaser up to like watch a github and just watch it? Automagically go from there.

Andres: Yes. In this case, you will definitely have to configure a gift of actions to listen to a specific GitHub events. So that is completely outside of the scope of any tool that you use. This is just regular GitHub semantics, but once you do, you can cook, can cook it in with any particular tool you want.

In this case, Jerry Lisa can be using this way. Your leaser can be consumed as a command line tool, regardless of the project of your choice. You mentioned that yes, it is written in Java, kind of hints at it by having a name, a J in the name at the front, but it can be used for any kind of project. So if you like Rust or Python and Node, Perl, even, even Python or something else, you can certainly use it because you only need an external configuration file, whether it be JAML, JSON, or TUML with these different formats.

And you could just run it in the CLI. So there is a specific GitHub action, JRELISA configure for GitHub that you can use that will read that particular external file and it will produce the the release. Now, if you happen to be using a Java project. Then there's also tighter integration with well known Java build tools such as Maven, Apache Maven, Apache Ant, and Gradle.

So whether you want to use an external command line tool, an external configuration file, or you use build specific plugins, the release tool will help you.

Jonathan: So I assume JReleaser is built in Java, right? That is correct. And do you, do you manage the releases of JReleaser using JReleaser? Are you, are you dogfooding?

Oh

Andres: yes, in the first place. So this is one of the things that we did since the early days. So the project started, if I'm not mistaken, the first commit happened around November 28th of 2020. So I was bored during pandemic. And so to say, I can give you the quick history of how this thing happened. Yes, I am a Java developer, but I also work with our search languages.

So I created a command line tool using Go. And I needed a way to release it. Now, I didn't know exactly how to do these things. I was looking around it and I found a nice project called go release it. If you're working with go languages, with the go language and producing these kinds of things, you owe it to yourself to have a look at go releaser.

com because the best tool you can use to release a go at the moment. Now I provide a lot of things, exactly what I mentioned before, create a GitHub page with a release and upload the assets create all the package managers files that are needed. And at the time it didn't announce. If there's something that it added later, thanks to Gerald Easter.

So it is a little bit of a cross pollination within the two projects. And so I was very happy with what Go did at the time, but I also continued to work on Java projects, and I needed a way, now that I know how it's easy to do things with Go, I wanted to do the same thing with Java, and there's no tool like that.

So talking with some one of my friends that did the same thing. So, I mean, he wrote a command line tool and wrote everything by hand to release the homebrew, create a Docker image and a post announcements, all these things. And every time that he needed to make an update, he will have to look at a bunch of scripts to find out what exactly needed to happen.

So we took those two things, those two projects as, as as an input and as an inspiration, and that's how Jerry Leaser, the tool came out to be. And since the first day. Since we're starting to push, really commits to the main branch, we, we use the previous version of Jeralyzer. We obviously had to do some sort of bootstrapping, but the previous version of Jeralyzer will be used to release the next version of Jeralyzer in some sort of early access snapshot fashion.

And the great thing is that this configuration file that we have for early access can also be used for a stable releases or final releases. And the only difference that we have is the, whatever input file, the input version of the project it is. So if I want to release version, the latest version is 1.

13. 1. Whenever I want to release 1. 14. 0, then I just need to click a button on my GitHub action, whatever, when my GitHub workflows I had configured in the project, give it what is the name the version number that I want to release, and it just happens. And I'm quite confident the release is going to work.

Because I have had more than a thousand releases happening every time that I do a push to main So this release configuration has been battle tested a long time.

Jonathan: That's it's funny It's also kind of funny that you've got one of your you know, like your your big final test Is the release like that humors me the the the?

That's what eating urine dog food means to some extent. But that's, that's funny that you've got that big test built right in. And like, if something were broken, you'd know about it. You'd know about it right when it was a problem.

Andres: Yeah, yeah, exactly. So we have plenty of tests like every other project, but we know for a fact, there are some things that will be very hard to test.

So the actual we actually testing production by releasing these early access pushes.

Jonathan: Yes, that's great. That's funny. So is this limited to doing releases of Java projects?

Andres: No, it's not limited at all. You can use it with any kind of source projects. We do have, as a matter of fact, on the website of the project which is jarlisser.

org, by the way, you can find a set of examples for non Java projects. So let's see if I can remember all of them that we have. We have C, C Perl, Haskell, Ballerina, which is JVM language, but it's not Java. And we have Ruby, I think. We have Crystal, which is statically type Ruby. We have Zig and I think we have, I think we have Swift as well and Rust, obviously, everybody's doing Rust these days.

So if there's something that I didn't mention, it's not that difficult to hook it in. Python? Is Python in there? I don't, I don't think I'd set up Python, but it wouldn't be that hard to set it up. So,

Katherine: I have a question. So I noticed when you released, so I did a little bit of looking things up. When you released, you announced that you can even do things like it announces your releases on Twitter or elsewhere, right?

Which is kind of fun. It's, you know, full automation from end to end, right? Making developer lives easier. What are people asking you for in terms of feature requests? Like, what can it do yet that you wish it could do?

Andres: Ah, okay. Well, it's worth mentioning that we support not only GitHub, but also GitLab and Gitea.

So if you have your own instance of Gitea, then off you go. And when it's both, in terms of GitHub and GitLab, it's both free versions and enterprise versions. That's not a problem. So we have, have had a suggestion to support Bitbucket as well. There is, as a matter of fact, a pull request pending. The difference, if you know what is Bitbucket, it works in a different way as GitHub and GitLab, in the sense that it does, the service of a Bitbucket does not provide what is known as a Git release page, like GitHub and GitLab do.

Andres: You will have to post create a document perhaps on Confluence and some of the sites, and then uploads all the assets in some way, some sort of attachments perhaps to that page. So if we were to do these things with Bitbucket, we probably would have to support additional tools in the Atlassian toolbox.

And that's certainly something that we want to do. But it's still it's still work to do.

Katherine: Yeah. Some people have, you could see a lot of value there. Yeah.

Andres: Yeah, some people have asked us also to assemble binaries using Deviant and RPM, which we can do. But for the time being, it's limited for Java projects.

We use a command line tool provided by the the Java development kit, the JDK, which is called JPackager. These ones create the files that are this, this kind of native installers, but they bundle a Java runtime because your project has to be Java. So if you want to create a Deviant file or an RPM for a non Java project we'll have to support that in some way.

And that's, that's something that we have in the roadmap and having a notarization for Apple or signing artifacts using the sign tool for Windows, which is kind of required for some installers. That's also some of the things that people have been asking, but we have yet to to provide those.

Jonathan: So I'm, I'm curious, I don't, you just mentioned Apple, but I don't think this is, this is part of what you talked about.

What about mobile applications? It. We, we, we think about this idea of, you know, doing your release and you have all of your manual steps you have to get done as a release and one of the, one of the projects that I've worked on that it was just a lot of manual steps to get a release together was pushing out like a new version of an Android app or I'm sure, I'm sure it's similar with an iOS app.

Is there support in JReleaser for doing mobile apps and getting things, you know, pushed up to the, the various places where they need to be?

Andres: Not specifically yet in the sense that if there is a specific channel or a specific remote service for publishing these applications, I mean, the App Store or in the sense of Mac is you have to both notarize This is something that could technically be done today outside of jresep, but tying it up in with the same configuration file.

Jresep has two mechanisms to extend itself if there's something that is not provided by the core mechanism. There's something called script hooks or command hooks you may think of as I mean, it will be as if you're configuring some sort of gif of actions within the configuration file for javalisa.

The syntax looks very similar.

Andres: the other one is a java specific extension that needs to be loaded by the java tool in order to provide the behavior that you want. Now, it's possible to do what you describe using command hooks or script hooks. Someone could certainly do this. The, the disadvantage is that it's as project specific.

So if there will be more projects, more mobile applications, I would like to take advantage of the things. And someone would have to either create an extension or we will have to figure out all the steps that were following this way and find a way to get it into add it into the core behavior.

Jonathan: So would it, would it be fair to just kind of categorize JReleaser as it's very much like GitHub actions, but run locally?

Andres: You hit it right in the nail. That's one of the things that we have. We have a drive run mode, so you can test your configuration locally as much as you want.

And another thing that is the reasons why we have these pushes for early access on, on, on every commit domain, because whenever we add a new feature, I can test this thing locally before I can push and then create maybe a faulty early access. So once you have your configuration or you're just getting started, You can set it up with drive run drive run equals throw all the time.

And then you just keep going, going, going, iterate until you find it. Okay. Now, apparently now this is good to go and then you can push it to the remote. And it is it is a lovely

Jonathan: feature that you can do things with dry run. I cannot tell you the amount of times that I've been working on something.

Particularly with GitHub Actions, because it is, it is, it is possible, but it is very difficult to run GitHub Actions locally. And even when you do it locally, it's not quite the same as running it up on GitHub. And so, you end up with about 15 commits in your project of trying something with GitHub Actions that didn't work.

Like, these are the commit messages. Trying something else with GitHub Actions. Hopefully it'll work this time. I'm about to give up. Why? Like, these are, these are real commit messages. Why is this in my life?

Andres: Yes, exactly. So, so yes, the tool allows you to test out things locally as close as you can.

And I mean, if you really want to, for whatever reason, you can also push out a real release from your local environment because you, because you may not trust GitHub or any other remote services with certain particular secrets. And that's fine. So, and the tool is designed to be used in both ways, local and remote.

Jonathan: Yeah. Is it, is it essentially the same running it locally and remote or is there, you know, is there some fundamental difference about if you run it on a service somewhere?

Andres: No, it's exactly the same as the same command line tool and the same configuration file.

Jonathan: Okay. What, what are the, what are the options for running it remote?

Like where does that make sense to try to do this remotely? Like is this something that will happen in AWS? Can you run, I think you said that there is a there's a J releaser action already built into GitHub. Like where, where are the places where you can have this in the cloud as they say?

Andres: Well, the my recommendation is that you pick your CI city tool of choice and then configure it there.

We have a summary finding the guide in the, in the webpage of the projects. We have, I think there's integration with 16 different services. At the moment, there is two that are specific, one that we already mentioned a couple of times, which is gif of actions, and the second one is GitLab CI, so as you may know, it uses docker containers, so, we do produce a docker image for jreser that you can use in any other way that you would regularly use a docker container, but this one has additional settings to detect if it's running within the GitLab environment, or the GitLab CI's environment, then it will set certain specific environment settings, So that it will do the right thing for you.

Jonathan: And then, and this is of course on our mind because what, two weeks ago now we we, we blue screened the entire world and CrowdStrike pushed out a bad update. Does JReleaser have test suite support in it and will it, can you set it up to abort pushing an update if one of those tests fail that you expected to pass?

Andres: No. And the reason being is that Java Elixir is a release tool, not a build tool. And this is the reason why we can support many different languages, regardless of whether it's Java or not. Because you keep using your build tool of choice, whichever it may be. Cargo for Rust, and Scones or Conan for C whatever it is, right?

Yeah. Once you have built your binaries, if you produce any binaries, Then you continue into the release process. And this is where Jeremy, sir will help you. Okay. So if there weren't any tests that were failing it will be a, steal the the job or your bill to find that out. And if the bill fails, then that's where you stop.

That being said Jerry sir does have support for additional security and supply chain settings. For example it recently added support for generating the input file required for GitHub attestations.

Jonathan: Okay.

Andres: So if you're released on GitHub and you want to use their recently added GitHub attestation feature.

You need some inputs and Jerry said can compute certain inputs, so it makes your job easier

Jonathan: that that would you that wouldn't happen to be related to a a certain compression library that contained a backdoor for SSH. Would it,

Andres: No comment? Yes, the other. The other option for at the station is salsa.

Yeah, yeah, it's also about that and that we do have a custom bring your own builder. That we built along with the, the salsa team. So if your project configures Chevrolet set and it's Java based where it's maven upgraded, they just pointed to our Java builder and it does the thing for you and it generates the attestation file and it will upload it to the release notes well to as a release asset into the same release that you just created.

We can also generate SBOMs and SWID tags, and SBOMs, whether it's SPDX or Cyclone DX, we support many different formats. Okay,

Jonathan: so I, I think You beat

Katherine: me to the S Bomb question. Well,

Jonathan: so let's actually, let's dig into that a little bit more. And I think I'm following along with what, you know, these, these acronyms and extended acronyms mean.

But for, you know, not everybody is in the weeds on this. So what is an attestation? What is an S Bomb? And why do people care about it?

Andres: So, an attestation is some sort of file that is signed, and that it proves the provenance of an artifact from a certain location. So you can, you can tell. That a certain binary has certain given signatures and hashes that it was created in a, in a given environment so that you can, if you as a consumer, someone can tell you this environment is safe and it has certain characteristics that you can verify this with the attestation and the artifact.

You can also verify that the producer, the person that is giving you is providing you the artifacts is actually the one that is saying who they are because of the signatures. In case of SBOMs, it stands for Software Bill of Materials, and that's something that has been known for quite some time, but it's now become much more important in the last two or three years for two reasons.

There is I think there's, I completely forgot the name of the of the memorandum that came out from the White House two or three years ago that says if you, if you are a software provider and you want to deal with the, with the government, then you must provide SBOMs. And in the European Union, we have a similar thing called the Cyber Resilience Act.

Now, these two things, these two things came out, have came out into force as law this year. So if you are dealing with government and offices, you must provide these additional metadata files. And because it's somehow most common in governments. Other companies will also start asking for these things regardless is governmental related or not.

So In in a few years ago, this was like, okay, let's figure out what it says bombs Maybe there's some tools do conversion what not now Place if you you are not ready to produce s bombs You must do it right away today after you finish listening to this podcast.

Jonathan: And a lot of that came about as a result of the, the big log for J vulnerability back about three years ago now.

So, and this is, this is something I kind of want your thoughts on because it's, it's, it's one of the things that I'm not crazy about, about Java. So when you build a Java application, you've got. Your entire library stack gets pulled into your, usually it's a jar that you distribute. And so what happened was one of those library bits was log4j, which is, it's just a piece of logging software.

It helped make your logs look prettier, right? But it had a, it had a problem, had a vulnerability in it that you could give it a, a bit of string and it would, it would essentially try to expand the string. And as a result, you could. Run shellcode you could run like command line code using this this specially formatted bit of string And the problem was that this thing was so popular.

It was everywhere like it was in Minecraft but because Logging is great. It was also accessible from everywhere. And so Like in the example of Minecraft, you could join somebody's server, send a message over the server, like, like sending a message from one player to another, and because it was trying to log that, you had remote code execution with this really trivial, you know, way to do it, and because of the way that Java builds these libraries right into the JAR, You can't just update the library.

You had to then update every program that contained the library. And so the thing that happened though is, there was then this question that every corporation and the governments needed to ask is, does our Java application contain that? What version of that library does it contain? And so then you had this idea.

I, it probably, it probably wasn't conceived of then it probably already existed. I honestly don't know for sure, but it became very, very popular because people suddenly saw it would be really useful to just have a list of all the libraries that this program contains. And so that's kind of where we, where we came to this, this point of.

S bomb software build materials are really important because there, there will be, I mean, obviously there will be another log for J there will be another vulnerability that is that bad. And people want to be able to get out in front of it a little easier this time around.

Katherine: Well, the whole conversation around dependencies is, is so, soft, I can oversimplify and say software is a lot more complicated than it used to be.

And so you look at these dependency trees, you know, and think about the good old days when you had a handful of dependencies and secondary and tertiary, but now it's, you know, if you actually draw a picture on some, especially web apps, it's kind of mind blowing. You can't even see it, it's such a mess.

Andres: Right. So, so basically SBOMs is just a recipe that lists all the dependencies that you have in your project, how it was built. And and because you have this list, then you can go to some other remote service and ask if any of those dependencies have any vulnerabilities. So the current focus that we have for SBOMs is check for vulnerabilities, but it's important to remark that SBOMs can do more than that because there's just many, I'll tell you that.

Right now we're just trying to check that if something is vulnerable or not, but we can do more than that just because we have that information about the project themselves.

Jonathan: Yeah. So there's, there's some other interesting things people are doing with SBOMs. I think groups like Tidelift are taking your SBOMs and actually saying, Hey, if you will pay us essentially a subscription fee, we'll take part of that fee and turn around and give it to the open source projects that make up your SBOM.

Like some really interesting things like that are happening being, you know, where this idea is being reused for things other than just vulnerabilities. It's really fascinating. I, I'm curious if you have any thoughts on, and again, I warned folks, I have just, just a little annoyance with Java and it's not just Java.

It's several languages that do this, but the fact that all of those libraries get built in at build time and the fact that that makes it more difficult. to up, to do an update when you have a library problem. So, on the other hand, on the other side of the coin, in a C project, where you have libraries that are just system libraries, you can just go and update the system library and fix the problem.

Like, it's kind of a bit more, let's just say it's more challenging in a Java project to do library updates, it seems. Is that, is that accurate? Is that a fair thing to say?

Andres: Well, so, I mean, if you have access to the system and do a patch that is affects the system wide, then great. You have admin, you have root, but if you don't, and then you, you get hacked, then off you go, all your C apps will be affected.

Whereas in a Java app, if it's contained to just a set of applications that are not completely system wide, then you only need to patch those. Now the problem is, find each one of those that may or may not have been affected. You may be lucky if it's only a handful. You may have a terrible time if you had to check every single one of those.

Jonathan: yeah. Okay, so What I, what I heard you just say is that I approach this, this conundrum from a very sysadmin point of view and not an application writer point of view.

Andres: Yes, kind of.

Jonathan: That's, that's an interesting observation.

Andres: There are pros and cons from both approaches. Yeah, yeah, that's,

Jonathan: that's true.

That's, that is, of course, true. Okay, what about what about Node. js and Kubernetes? It's hard, it is hard to talk about like this style of problem without thinking about things like, what was it, right pad, or was it left pad? Left pad. Left pad, yes, yes, yes. The single, the one liner JavaScript library that someone decided, you know, they weren't getting supported for it, so they just pulled it and made it disappear.

It's difficult to talk about the supply chain issue without thinking about left pad. So does, does J releaser help with no JS and JavaScript applications as well?

Andres: For, in the, in the case that we just described, I mean, dependencies and all these things. No, it's a, it's completely out of the scope by the service that allows you to publish the packages and consume them because that particular service and okay, I mean, this happened, what, like eight or nine years ago?

It's been a

Jonathan: while ago now. Yeah.

Andres: Yeah. I have not been kept up with times, but the problem at the time was that that particular repository was not read only or a pen only. So you could modify it. And that's exactly what happened. Someone said the the author of Lepa said, I'm, I'm angry because I mean, we can talk about this, the story, but he said, okay, I'm going to unpublish my packages.

Mm-hmm. , because this is what you did to me is, is not what I was expecting. That boom, that broke the internet for three days. In the case of Maven or in the case of the Java system, we have this repository called Aven Central, which is a panel only. So once you publish a package, it's stuck there.

You cannot unpublish. So if you made a mistake, well, sorry that stays as it is. And if you made it right, then also it stays as it is. So that's a real advantage.

Jonathan: Yeah. And so can, can you use can you use J releaser to, to push no JS packages?

Andres: Right now, if it's published as a regular HTTP yes.

If we need additional support for, I mean, if it's more than just a simple By simple, I mean post or put and be authenticated. We probably need to add a specific support for it, but if it's just a regular HTTPS endpoint where you do a post and a put, then yeah, you're good to go.

Jonathan: And I suppose because in JReleaser you've got like script hooks, so you could, you could probably just hook in to run a bash script as part of your release process, right?

So really, so really the sky's the limit. You don't have to have support for all of these things. Like I could, I could sit here and we could ask about, you know, every package manager out there and every language out there. But the, the reality is you can write your own script and have J release called script and you get there that way.

Andres: Yes. So obviously the advantage on cool is that there is already a DSL where you can define all the kinds of configuration. And this DSL works for every single environment running environment that scribe before where they see a live. Or is Maven Gradle plugins and end all those things. Now, this DSL allows you to reuse common configuration that you have for the different steps for Excel or, or settings.

So there is project common configuration, like what is the name, what is the tag name? Version number, release name, stuff like this project project author, links, text. So many different things. And then there are sections where you configure the actual release. Mm-Hmm, . Where is it going to go? Is it going to be to GitHub or GitLab or something else?

And you also can configure release notes. So this, this is something I wanted to come back something when you mentioned where you're trying things locally and then you create a bunch of, of, of commit messages. We always do, we most likely use throwaway commit messages. But if we don't do, we don't squash it, we don't rewrite those, those trash commits will remain forever into our history.

So one thing that the tool allows you to do is generate a release notes based on commit messages. It's not the only tool that does it, but this is something that if you define your own conventions and by the way, we support out of the box, conventional commits or gitmoji conventions it makes your life much, much easier.

So all these things make sense when they are completely baked into core. If you want to use a script hoops to support The package manager that we don't support yet, you can certainly do this. But I mean, if you feel that maybe it's too wonky, yeah, it kind of works, but if it would be better to have support of core, we certainly would encourage those people that write a custom scripts to come back to the project that open a discussion topic or an issue so that we can track this and then figure out a way how we can add that behavior back into code.

Yeah, absolutely.

Katherine: So when you talk about things like release notes, I start thinking of like I don't know. I mean, I, I feel like every project kind of has their own style in a way about a lot of things, not just release notes, but talk to me a little bit about extensibility. I mean, again, projects have their own needs.

And if I have specific needs, what, what can I do? I under, I believe you have an extensible architecture. I can write some sort of plugin or something to customize it to my own needs.

Andres: Yes. We have an extension mechanism and there is a handful extension points at the moment. So the the full configuration, the whole, the whole life cycle is not yet extensible.

We're just adding, well, a few extension points at the moment. And one of them, it is that has not yet been added, but it's something that we have in the roadmap, is fully configure how release nodes or the changelog gets gets created. We have the options to, already, to parse these conventional commit settings, or you can define your own presets, your own conventions in, in declarative way we can also take in a changelog from an external file or instruct GitHub to use their native way to generate release notes based on issues and pull requests if that's what you want.

But if you want to post process this release notes in some other way to, I don't know, change some text into emojis or do some kind of text replacements, it might make sense to write your own custom extension. And this is something that will certainly be added into the future.

Jonathan: So one of the, one of the interesting things that you can do and again, I'm most familiar with, with using GitHub for this sort of thing.

That's why I keep going back to it. But one of the interesting things you can do with GitHub is you can make your you can make your release process like transparent. People can look at it. It can be part of, you know, your, your GitHub code that's out there. But then when you do that, you, you suddenly have this problem.

I'm like, how do you. Keep all of your your keys secure and secret. Because obviously you don't want to leak. You don't want to leak a organizational GitHub key. You don't want to leak an AWS key. And there, people have come up with ways to do that. And there's even some tools out there now to scan for those things, to make sure you're not leaking them.

I'm curious whether this makes sense, like, is this a thing with J releaser as well? Can we make our J release? It's not exactly a script, essentially a script. Can we make that public? And if we do so, do we, do we still run this problem of, you know, leaking secrets that really should not be leaked?

Andres: Certainly you can, you can make it public as a matter of fact, the Jerry's her project has his own release configuration made a public and everyone can see that they are certain elements with property that given setting is a secret.

So they, because we know certain property, so take those inputs coming from environmental variables. So it's up to you to provide the secret in a proper way with gift of actions. And using environmental variables and that's something the same thing that you can do on your local environment.

Jonathan: Okay, that makes sense Yeah, good stuff.

So let's see As you as you look at as you look at the jrelease project What what do you see coming up next? Is there something that you guys are working on already that you're you're excited? Well, you know before I even ask that there's a couple of other questions that I wanted to get to and and that is well First off, what license is this released under?

We talked about asking people to push things back upstream. What license did you guys go with?

Andres: We went with Apache v2, this one. Okay, so that's a And we also have a CLA.

Jonathan: Oh, okay, okay. That's a pretty permissive license. Let's people do pretty much what they want to. Now, I'm curious, what's the rationale behind the CLA?

Andres: The CLA was done so that if in the future we would mind to relicense a project then we don't, we don't need to hunt down every single committer to make this happen. So for those that are in the Java space, there's a very well known project called Hibernate, which is an object relational mapper.

Everybody likes it. And there's also a lot of people that hate it just because it's an ORM. And it started with a GPL license. And they wanted to migrate to Apache v2. It took them more than three years To search for every single committer to ask them for the permission to do this license switch So the one of the advantages for a project that have a cla is that if you write down in the cla that Well, not only that everybody has to sign it so you can know who who there are how to contact them But also if you write down in the cla that the the project The the commit has given the rights to the owner of the project.

In this case it will be me.

Andres: Then I have more limiters to do in the future, but obviously this is not some evil ploy to do something in the future. But it's just to make sure that, to, to put out things in the open again, to, to ensure that if you are willing to commit to contribute to the project, then know that these are the conditions and you're fine with this, then go ahead.

Yeah, you

Jonathan: know, I'm, so I, I'm part of a project that has a CLA as well. And it's for very similar reasons. It's the, the, the reason there is if we discover in the future that there's a problem with the license, this gives us the ability to relicense it. At the same time, you do see businesses and projects out there that have CLAs that let's just say they use that power for, for what some might consider evil.

Right. And I w I wonder whether it would be possible to write a CLA that Is a little more, a little narrower than simply giving all rights to, you know, the, the upstream organization. I wonder whether we could write a CLA that just says the upstream organization has the right to relicense this to any other, let's say, OSI approved license.

I don't, I don't know if anybody's doing that, but that seems like that could be an interesting interesting way to handle this. You know, give, give a project some tools to fix things. If things go wrong, we're at the same time giving the people that contribute a bit of assurance that look, we're not looking to sell you out and go make millions of dollars on the backs of your code.

Right?

Andres: Yeah, exactly. I completely understand. And I agree.

Jonathan: Yeah, that's, that's an interesting thought. Okay. So you, you, we also have talked about other people contributing things. What does that look like in JReleaser? How many, how many people are working on this and how many contributions do you get from outside?

Andres: We have a small team working on the team, on the, on the tool, but we do use don't know. And this is also sort of conversion, but it's another application that you can set up on GitHub since our GitHub action is called all contributors. And with this, you can have a very nice looking markdown based documentation where you see the avatars as every single contributor.

And they are listed by the type of contributor they made, so whether they fix code, they are announcers, they promote the project, or they're doing documentation, internalization, so there are many ways. So for every single contribution that is made for the project, whether it's just one typo, or it's a big contribution, we list every single contributor over there, and I believe we're past 70 contributors at the moment.

Jonathan: Yeah, that's really good. And you get a lot of I call them drive by contributions. It's where someone has one specific thing that's either broken or, you know, that they want added, and they, they drive through and they drop off their patch. Here's this new feature, and then you never hear from them again.

Is that fairly, fairly common there?

Andres: We have had a few in that, in that regard but those that are part of the the core team Most of them have joined us since the early days again, since since 2021 started discussions on how the two could work. So I will say that it's it's, it's a herd. I mean, it's a healthy mix of long time contributors, even though small set and just quick contributions from all around the world.

Sure, sure.

Jonathan: That makes sense. All right. And then I was, I was going to Let's see. What was the question I almost asked?

Jonathan: What what's coming up? What's what's in your roadmap for the future.

Andres: Right. So, so in the early days of the tool the reason why it was written. So it was so that I could release a command, a Java command line tool in many different aspects. Now for this to work, the package manager has to understand that your binary has certain file structure.

So they will know what to do with this onManifest and every other file that it requires. So for, for this to work, we have diff like a set of distribution types. There's your standard Java binary where it has a, a, a script or a launcher. And the list of jar things that have been asked for the tool is to support source distributions.

Once we do this, then how we will be able to create source RPMs. Or deviant files for sources or support any other kind of package managers that will deal with source distributions other than binaries is something that will certainly be looking at how to make it work.

Jonathan: Yeah. Interesting. All right.

Katherine, anything you wanted to ask? I think you've covered

Katherine: it. I

Jonathan: get down towards wrapping. I,

Katherine: I don't know. I think you beat me out to all the questions.

Jonathan: Sorry. Okay.

Katherine: Yeah.

Jonathan: So I'm, I want to know, is there, is there anybody out there? Is there a project or anything that you know of that's using J releaser in a way that just surprised you?

Is there anything weird? Yeah. Are there any surprising uses?

Andres: So there's actually some sort of interesting look within one of the, our inspirations for Jerry cert the project that I failed to mention it before is called J bank. It's a command line tool that allows you to launch Java applications in many different ways.

And once Jerry reached a certain level of maturity, J bank decided to complete it. Their own manual way to do things and use Jarlisa. And both Jarlisa and Jbank use a package manager called sdkman, which allows you to install binaries just for the Java platform. So this is like, similar to RVM for Ruby, I believe.

As a matter of fact, that was the original inspiration. And I am, I am in talk, well, I was in talks and I'm, I'm not, I'm kind of a member for the SDK package manager as well. So at some point, sdkman also uses Jarlisa. For some releases. So the three projects are kind of like joined at the hip. If something goes wrong with Jarlisser, then obviously Jbank and SDKman will know immediately what happened.

And one more thing that I can say happily is that these three projects alongside alongside other six are now members of a brand new server foundation called the Common House. You can go to commonhouse. org. The idea behind this foundation is that we want to provide a long term home or a forever home for open source projects.

We started with we're targeting well known Java projects, but it's nothing, this is not that it's close to non Java projects. So in the future, for sure, we will be able to support any other kind of project right there. Because the whole point is that if you have a project that has has created a good impact in a certain open source community.

And you feel like, I mean, the maintainers that they, it will be better to be supported by the umbrella and the facilities of an any given foundation that common house will probably be one of those options.

Jonathan: Yeah, interesting. All right, we are, we are getting towards the end of the show. Is there anything that we did not ask you about that we should have? Anything you wanted to plug or let folks know about?

Andres: One more thing is that we decided as part of the team to have a very deterministic release cadence.

We release a final release every two months. So if you are a consumer of the tool and you know that there is a feature that is upcoming, then you know that it will not take more than two months for this thing to be released or to be available in the next release. Another thing that the tool does, and we do use it for our own releases as well, is that every time that our release comes in, you can configure to have the set of issues that are related to that particular release.

To have a release label attached to it and add a new comment. I said, this issue was released on version such and such a link to the release notes, because this will notify the author of the two of the issue right away. So besides this, you can say I'll come publish to a slack or email or to Twitter.

Then I can also notify through GitHub and GitLab through their issue tracker mechanism. That there, something has been done. Something has been released. Oh, that's really cool. Also, we get that notification

Jonathan: that's that's, that's really useful that you can do that. Alright. So it, it takes you like two

Andres: or three properties.

Jonathan: Alright. One other thing that I, hang on, hang on one second. The technical issues have been terrible.

Katherine: Uhoh technical difficulties. Again,

Jonathan: let's see if I've got him back.

Katherine: Are you, are you the, you are the solo maintainer, right? Are. Are you the only lead maintainer on this project?

Andres: I'm the lead maintainer, yes, and we have two other people that contribute to the project, but I'm, I'm doing most of the work at a time.

Katherine: That was, yeah, percentage wise, I'm curious. So if, if you get tired, do you have a succession plan?

Andres: That's exactly why the project moved to the Common House Foundation. Because that is one of the tenets of the foundation to ensure that it's a succession plan. And this is something that we will continue to work on in the coming months to ensure that if something were to happen to me, then someone can continue with the project.

That's great.

Jonathan: And, if something God forbid, but if something happens, it's going to be easy for them to win the lottery. Well, it's going to be easy for them to continue doing releases because you've got your release script published right there in the public, right? Exactly. Yeah. I liked it. No, that's something actually that I've, I've thought about again, several projects that I've been involved in.

We have kind of this idea of like, who's going to take it over or, or, you know, maybe even it's not established, but you kind of get the idea. Well, it would be easy enough for one of us to pick it up, but then it's like, whenever a release comes around, it's like, what all does he do to do a release? And the steps, sometimes the steps are not easy.

Katherine: And even when you really all that good at documentation,

Jonathan: nobody is, nobody's good at documenting the steps for a release. You just, whoever does it gets it figured out and then just kind of does it at each time. I think, I think there's something to be said for J release or just for that. Just for the idea that it forces you to document your release steps.

And I think that's useful in and of itself. All right. So I do want to know favorite text editor and scripting language.

Andres: Huh. So my favorite text editor is a Vim. And if, because I like to be on the command line and if it's not in the command line is text made because I used a Mac and a scripting language.

Andres: Well, I started with Perl, then moved to PHP, and then jumped into JavaScript, and from then I jumped back into Javaspace, and I fell in love with the Groovy programming language.

So if I have to say just one of those, then I would go with Groovy.

Jonathan: Okay. Groovy is one that I am not particularly familiar with, so that's pretty fascinating. Is it I don't hear that

Katherine: a lot.

Jonathan: Yeah, does it it uses the JVM as well?

Andres: Yes. You can think of groovy as dynamic Java. Okay. Interesting. So the syntax is 98 percent equal and it's very easy to interchange the Java code with groovy code from within a groovy script.

Cool.

Jonathan: Very cool. All right. Well, thank you, sir, for being here telling us all about JReleaser. It's super interesting. For a couple of projects I do, I need to look into it. So we sure appreciate your time and bearing with us through a couple of technical difficulties. And we'll make all of those disappear, I hope, in the edit.

Katherine: Nothing to see here. Exactly.

Andres: Thank you so much, Katherine and Jonathan for having me

Jonathan: here. I really enjoy it. Yes, was, was very fun. Very much, very much appreciated. All right. Katherine, do you have any projects that need the J release treatment?

Katherine: Not at the moment, but I, I was thinking the whole time as I I'm listening to the, the, you know, all the marvelous things that it does.

How nice it would have been to have it in the past.

Katherine: That is really it, you know. I, I, I like to think that I've documented release processes pretty well because, only because I, you know, I come from a, a, a position of like, explain it to me like I'm five and, and if I don't document it for myself, I will mess it up.

So so there's that. But I, you know, it, it making, Things easier so that you can focus on the hard problems is such an important goal. Yeah, yeah,

Jonathan: for sure. Yeah, we didn't, we didn't explicitly ask him about this, but I bet you could use J releaser to even do things like push website updates and, and other, you know, not maybe not the things you would normally think of with it, but.

I'm sure you could script it and make that happen. So documentation updates, probably all kinds of stuff you could use this for. And, and again, so the, the, the point there would be you, you have it automated, you have it scripted so that you just, you, you, you run one command and it makes it happen. So like we, we think about doing an update for a piece of software.

Well, it's actually. In some ways, it's a similar thing when you do an update for a website, depending on how the website's put together. Sure, it's

Katherine: powered by software.

Jonathan: Right, right, right. And so, you know, on this side, it's not necessarily a programmer, it's a sysadmin doing it. But you have some of the same problems.

What happens when one sysadmin retires and the next one comes in? It's Okay, how do I update this? Maybe even, how do I get to the server? Where is the server that runs this? And I'm just, I'm just thinking like, this could be a great tool in the toolbox of like, IT departments and sysadmins to be able to do things like that.

So, a very, a very interesting project. And I like the fact, I really like the fact that That it's, you know, it's JReleaser. It was originally made for doing Java releases, but the sky has been become the limit for it. And they've, they've made it as modular as possible. So you can do all kinds of fun stuff with it.

Katherine: Yeah, I like, there's a lot of interesting stuff. A lot of, there are a lot of tools, I think coming out with JReleaser. The idea of making developers lives easier. I'm surprised we got through an entire, an entire episode without mentioning AI, by the way. So that's maybe for next time.

Jonathan: Yeah, I guess. I don't know.

This seems like maybe, maybe one where AI does not fit.

Katherine: Does it though? Automating things? I don't know. Automating. Processes. Do you,

Jonathan: do you really, do you really want to give AI the ability to push code? I don't, I don't think so. I, I think this is something that needs to stay out of the clutches of AI. I don't know.

I

Katherine: can see a little, a little, a little AI improving my release notes, you know.

Jonathan: Okay. Okay. I suppose.

Katherine: People, that's the thing. I think there's a lot of, a lot of like, Fear about AI and anxiety. That's unwarranted because we don't, we don't realize how many mundane things AI is actually used for. People think of you know, the, you know, the robot overlords will push the malicious software, but it's really like, I, I, can you just spell check my my release notes on an automated way?

Jonathan: Yeah. So yeah, that's true. You can, AI in your processes without giving it the keys to the kingdom. Right? So, you know, we, you think of the dangers of AI and people automatically go to that, that thought of Well, that's how you bring about the singularity, right? You give AI the ability to improve itself.

Well, That's not the only way that you can use this tool. You can give AI the ability to tap you on the shoulder and say, Hey, you might want to think about changing this because it sounds weird. Yeah. Anyway, that's a valid point. We will, we'll bring him back on one of their next big releases, and we'll ask about AI, and see if that's something that they're adding.

And

Katherine: then he'll roll his eyes.

Jonathan: And he'll tell us that, No, AI has no business being a part of your release project. What are you, crazy? Alright. Katherine, thank you so much for being here. Did you have anything you wanted to plug?

Katherine: Sure. Let's see. Yeah, there's that other part. So I do another podcast at Intel open at Intel.

Occasionally, I still do a podcast with DocsRules, although I need to get on that reality 2. 0. Let's see. I will be giving a bunch of talks. Yeah, starting in September, I'll be at Open Source Summit EU. I'll be, I'll be talking a little bit about AI and a little bit about security. So that's fun. And then I'll be doing it again.

And oh God, so many times.

Katherine: Yeah. Yeah. Yeah. I don't know. Find me on the internet and I'll tell you all the other times I will be talking about these things, but yeah. Grace Hopper for sure. All things open. I'll be at KubeCon probably also for sure. Sauce fusion in Atlanta. So that's an open SSF event.

That's something to plug open SSF stuff. A lot of really cool stuff going on there. We hinted at a little bit of it earlier with salsa.

Jonathan: Yeah. Yeah. A little bit going to be at, going to be at Defcon this year. Is Defcon on your, kind of on your radar?

Katherine: I would have, but I have so much travel coming up after that.

I need, I need a little time to, to, to. Be at home.

Jonathan: Alright. I understand that. I do. I do. Alright. Well next week we have another Java project. We're talking about LifeRay. I don't know a whole lot about that yet, but it is sure to be interesting. And I know it's a Java, it's a Java thing. In fact, when they, when they reached out to me, it's Olaf Koch and David Nebinger.

When they reached out to me, they're like, so we heard you mentioned Java. How would you like to do a Java project? I'm like, okay, fine. Oh, so that is next week. It's, it's, it's the second part of our two part Java extravaganza. So make sure and come back for that. And then, Oh, yes.

Katherine: Sorry. No, finish your thing.

Or I'll just interrupt and think I can't believe the most important one. I forgot. I will also be at Intel innovation where everybody should go. I put like, I forgot like the most important event.

Jonathan: You, you, you had one job, Katherine, right?

Katherine: I had one job. Intel innovation that comes right after open source summit, though.

So it's like in my head, it's all one thing, but that's going to be a big thing. I'll be doing podcasts on the expo floor and there'll be all kinds of like meetups for AI nerds, and it's going to be cool.

Jonathan: Cool. Very cool. So there you

Katherine: go. I got that out.

Jonathan: All right. Well the one thing that I do want to plug with the two thing, a couple things, several things to plug we've got hackaday, you can follow my work there on hackaday and most notably, we've got the security column goes live every Friday morning.

And, of course, we do appreciate Hackaday being the home of Floss Weekly. It's, keep your, keep your internet radios tuned to hackaday. com, and enjoy all of the coverage there. And then we've also got the Untitled Linux Show over still at the Twit Network. We have a blast there. You can catch that, it goes live we do the recording Saturday evening, Saturday afternoon, depending on where you're at.

And then within a couple of days that goes live, make sure and subscribe to that for all of the Linux news and musing that you need in your lives. I think that is it for today. We sure appreciate everybody that's here, both live and on the download. And we will see you next week on Floss Weekly.