Wicked Good Development Episode 7: Devnexus reflections and conversations Part 1

Wicked Good Development is dedicated to the future of open source. This space is to learn about the latest in the developer community and talk shop with open source software innovators and experts in the industry.

This episode is the first in a three part series from our experience at Devnexus 2022. It was an exciting time to learn from developers and capture wisdom from the open source community. The life of a contributor told by Maarten Mulders, Consultant, Trainer, and Technology Advocate at Info Support, plays out on Wicked Good Development during Devnexus 2022. Considering Apache Maven to be the cornerstone for Java development, hear how Maarten navigates fixing bugs, avoiding build breaks, and Java derivative languages.

You can jump forward to part two or three.

Listen to the episode

Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm

Show notes

Hosts

• Kadi Grigg
• Omar Torres

Panelists

• Rohan Bhaumik, Product Manager

• Theresa Mammarella, Developer Advocate

• Steve Poole, Developer Advocate

• Rishav Mishra, Product Manager

• A.J. Brown, Principal Engineer

• Maarten Mulders - IT Consultant at Info Support

Transcript

Kadi

Hi, my name's Kadi Grigg, and welcome to Wicked Good Development. This is a space to learn about the latest in the developer community and talk shop with OSS innovators and experts in the industry.

Omar

Hola, my name is Omar, and today I'll be your co-host. We are dedicated to the future of open source and we will be bringing you the latest in open source.

Kadi

For today's episode of Wicked Good Development, we have a team here from Sonatype where we'll be unpacking the Devnexus trade show we just came back from in Atlanta, Georgia. Before we jump into it, I'd like to ask each of you what your role is and what brought you to Devnexus.

Steve, you want to go first?

Steve

Yeah, well, of course. Yeah, so my name is Steve Poole. I'm a developer advocate and I go to Devnexus because it's Devnexus. It's where all the Java guys hang out.

Kadi

A.J.

A.J.

I am A.J. Brown, I'm a principal engineer at Sonatype.

I was a last-minute tag along at Devnexus. So I spent most of the time in the booth talking to the developers. I think what I wanted to get out of it is, I work in the research Sonatype and had some wanted to get some feedback on, you know, affinity management frustrations around that, and test some ideas that we've been looking at in research.

Kadi

Thank you. Theresa.

Theresa

Hi, my name's Theresa Mammarella and I am also on the developer advocate team at Sonatype. I have been a Java developer in the open source JDK space for about five years. So Devnexus was all about introducing myself to in this new, from this new lens of developer relations and getting to know more Sonatype employees.

Kadi

Rohan.

Rohan

Hi, I'm Rohan Bhaumik, I'm a Product Manager at Sonatype. My interest around participating at Devnexus was to try to get a sense of how attendees at the conference or a mix of, you know, people who are active in open source and those who primarily do a lot more of traditional corporate software development type jobs. Try to look at problems around code quality and dependency management like A.J. touched upon. So it was really exciting for me because I think we did get a lot of good insight there. It was also my first actual dev conference, so it was cool. Totally would do this again.

Kadi

And Rishav.

Rishav

Yeah. So similar to Rohan, I'm also a Product Manager at Sonatype I'm Rishav Mishra and the primary reason why I went there was one, because obviously we've all been stuck at home for a long time and it was great to see the developers or the colleagues. And one of the key takeaways from me from the conference was really getting to understand what are developers thinking? What, what are the pain points? What can be? I really wanted to get inside the head of the developer and see what they rant about in the bar. And I literally did that. So it was this amazing.

Omar

Well thanks, everybody for being here. Now that Devnexus is over and you've had a little bit of time to reflect, I'm curious about what your impressions of the event were? What are your thoughts on the event? Any, any major takeaways?

Steve

Yeah. Okay. The last real developer conference I did before COVID was Devnexus. So it was good to do the first one again, at Devnexus. We were all: I, you, those of us in the space, the conference organizers, different people, who are all trying to figure out whether it's going to — how much of a success it was going to be.

And what we've said is it was a super success. And that the expectation that we had that people really want to get back to conferences. Speakers, obviously, those of us in the software industry, obviously, and then the attendees, and I tell you that the feedback was, everybody was super excited and they were so glad to be doing this.

I went straight for Devnexus to Devoxx France, which is the week after, where they have a hundred percent of their usual audience. And some of the conferences coming up with I'm talking to people and they're suggesting they may have more than a hundred percent. So my takeaway is that the whole conference scene, which has been on hold for two years is now back on and probably more exciting than ever.

A.J.

Yeah. I want to just reiterate something that Steve said, which is like, it's great to be back out in the wild, you know, talking to anyone really. Right. You know, I spent the last two and a half maybe, what, year is it? Yeah, two and a half years, two years, two and a half years, uh, talking like this over a microphone and over a screen or whatever. To actually see people's faces and the reactions and, you know, for me, when someone who's looking for feedback, getting like body language responses. It is really good and you can only get partially body language responses over a camera. Unless you’re like me and you shake your hands a lot.

Right? So that, that was great.

Rohan

So, for me at Devnexus, personally, I was like, kind of bummed out that I didn't get to watch a single talk. What I will highlight is that this was my first experience manning a booth at the conference. And I have a lot of respect for people who do that. So a big respect for everybody who does that.

Kadi

I think what's something that you've touched on was interesting. It's great to be back in person, right? Reading the body language. And for me, I know I had a conversation with Brian Finster, you know, it was one of our conversations we had there where I hadn't seen him in two years and it was like, time had stopped and all of a sudden you were like, oh my gosh, is that you again? And I know many of you had also participated in some of these conversations we had this, you know, last week and I just wanted to get what were some of the impressions or takeaways you had from that.

A.J. I know you specifically spoke with Maarten about Maven Central and there was a lot of good stuff there to unpack. Can you talk a little bit about that?

A.J.

So one of the interesting parts of that conversation was I asked the question about like the future of Maven. We talked a bit about like the difference between like Gradle and Ivy and these other competing, and use it in quotes, build systems.

And I think we were kind of on the same page there, but I kind of threw out there, you know, people like myself and I don't think I'm alone, like, you know, Maven doesn't move very fast and that's, that's probably a good thing because they figured out all the right things, right. Pretty early on and just iterate on them.

Sorry, iterate on them. Whereas, you know, Gradle could be seen as more revolutionary. But then we started talking about how that is the configuration over convention can be an issue because now you're actually writing code into your build system, which then needs to be maintained. Which is this kind of weird thing, right?

You've got to maintain code for your build system that maintains your code. So that was a very in conversation. Then we got on what's the future of Maven and I'm gonna get this version wrong, but I believe, uh, the next, okay, I would say the next version of Maven decoupling, the POM that your application uses to build versus the POM that's actually published was and interesting concept.

And that was a lot, had a lot to do with backwards compatibility. What I find great about that is the thought that is really put into, “Hey, we don't want to break the world’s software, but we want to introduce these new features. Right. And some of them are big changes. So how do we do that?”

We're going to make a fundamental change to the framework without forcing everyone to upgrade. Right. I really appreciated the thought that open source contributors like himself put into that, knowing that like Maven runs the world, right. Or at least a large part of the world.

Maarten Mulders Interview Begins

Kadi

Hi. Can you just tell us what your name is, where you're from a little bit about yourself and why you’re here at Devnexus?

Maarten

Yeah, sure. So my name is Maarten Mulders. I work at Info Support, a Dutch consultancy firm. I'm primarily a consultant, also a trainer, and a technology advocate. I'm here at Devnexus because I was delivering a speech yesterday about working on Apache Maven. So that's why.

Kadi

So what interests you in Apache Maven to give a whole talk about it?

Maarten

Well, in fact, Apache Maven is in a way a cornerstone for Java development. I'm sure there are alternatives to Maven there's Ivy and Gradle but I think we can be pretty sure that most Java developers use Maven in their day to day work to build the projects, to run their tests, to basically do that, day-to-day work with the Java language.

And so in that way. It's a cornerstone for people to actually work with Java and being able to contribute to that cornerstone is making an impact to millions of people. That's just amazing. Isn't it?

Kadi

Yeah.

A.J.

So how long have you been a contributor to Apache Maven?

Maarten

I think two or three years by now.

Yeah. And it started with like really tiny little improvement things, and then it grew all the way became more serious. And eventually I was invited to become a regular committer as well. So that's where I am now.

A.J.

So you talked about some of the alternatives to Maven like Gradle, Ivy, those things.

Other than maybe other than Maven, that’s used the most, can you maybe talk about why you should use a Maven, not a Gradle or Ivy- what's the benefit of sticking with Maven?

Maarten

Well, for me, the main reason to use Maven, other than, any of the other tools would be that Maven is really pushing you in a certain direction.

So it's basically saying this is the recommended approach. Do it this way. That actually means that sometimes you have to compromise a bit. Some people say it's not that flexible. I just wanted this a little bit different, but on the other hand, if you, for instance, take Gradle, and I'm not here to flame them or something, but, what I've seen happening is that people are like, “oh, I can do this, I can do that,” and then at the end of the day, it's like, “but why is my build misbehaving? I don't actually understand where it's going wrong.” Right?

The flexibility gives you a lot of power, but that power means responsibility for setting up your build properly. Right? I mean, yeah, it's as simple as that. Maven, on the other hand, it's like, please do it this way because it's guaranteed to work.

This is going to work because it worked for everybody. Right?

A.J.

That's interesting. So I probably had like a period of maybe a year or two where I was like, oh, I like Gradle way better for the reasons you said, right. It's like, instead of having to find a plugin and do a certain thing or write a plugin, like I'll just write a little script, but then that's something that I've got to maintain.

First is you get the advantage of, if it's a plugin, other people might maintain it or it's structured in a way that makes sense. Start to go. Right. That's I agree with that. Yeah.

So, I want to talk more about just in general being an source contributor, you said you started with the small changes, then you started doing more and more, right?. How do you… if I wanted to join Apache Maven now, how do I?

Maarten

That's a good question, actually. And that's one of the things that we addressed in the talk that I was giving yesterday.

There are a couple of ways, and I would actually make the distinction between contributing and committing. Contributing is way more, I've mentioned it a few times yesterday, but sometimes a well-written bug report is more worth than a bug fix. It's excellent that you understand the code and are able to fix it. But what was the problem that you tried to fix?

So contributions in any form are already more than welcome. And if you have like, “Hey, I don't understand why this doesn't work?” or “I'm pretty sure this is a bug because the documentation says A but, “Hey, but I observed behavior B. Writing the bug report in itself is already providing value to the community.

Then it's even more amazing if you can turn that into a fix for the problem. Sure. But the first step is observing, and discussing, “Hey, is this actually what we intend?” or “Is this a bug?” or “Can we maybe enhance over there?” Then contributing is basically starting the discussion. That's already a contribution.

And from then on, it can only grow because maybe it is like, “Yeah, you're sure that that's, that’s a bug indeed.” We can then go and take a look and try to fix it. If you're comfortable with that of course. Maybe there's not something that you observe and that, that is a nuisance to you, that bugs you, but you're more like, “Hey, I want to contribute anyway.”

That's perfect. And we actually have a dedicated list of issues in our issue tracker, which are labeled up for grabs, which are like, even if you're not a Maven expert, even if you don't know the codes bay from A to Z, from heart, that's perfectly fine.

These topics don't require expert knowledge. They require that you know Java and you're a Maven user. So you probably do know Java, right? Right. Care to take a look and you can already provide value to everybody using Maven. So that's also a very good way to get started.

A.J.

I'm interested in the politics of open source projects.

Right. So you said that you're looking at a bug and you're trying to decide if it's intended behavior or it's actually a bug. Are there moments where like there's disputes on it? So like, I wanna introduce a new feature to Maven and you might think that's not really what Mavens for- how does that get resolved?

Right. Because I mean, you're one of many other people that are one of many maintainers of Apache Maven, right?

Maarten

Yeah, that's right. That's a community thing. Which means that you as a user, as well as the community that actually maintains Maven, are actually exchanging information, views, or arguments on that particular issue.

And sometimes this means that we end up with a situation where not everybody fully agrees, but you got to move on anyway. Not doing anything at all is also a decision.

A.J.

Right.

Maarten

Doing something is also a decision. And it was like just recently that we had a feature added to a compiler plugin that not everybody agreed with.

We had like discussions on Twitter and on the mailing list and it went on like this, asking would it be okay to add this? And some people were like, no we shouldn't be doing as well. We did it eventually, regardless of the fact that some people said, “no, I don't like the idea. We shouldn't be doing this,” but yeah, you can't really satisfy everybody, can you? I mean, you got to make a choice anyway, so yeah.

A.J.

Yeah. So are there people that are experts in certain parts of the Maven pieces that might make that call? Or is it, is it really like, I need to get consensus on this if I really want to drive it forward and if I don't, we don't do anything?

Maarten

Yeah, well, formally there are no expert leads or something. In practice, however, there's always like, “Oh, it's about that particular plugin. You better ask that person.” or “It's about, it's about the modular system. He knows a lot about that.”

But then on the other hand, proposing an idea for a new feature is something. And then typically the people who work on Maven on a regular basis, we'll be like, “Yeah, well, I liked the idea, but I don’t have the time.”

It's a volunteering effort anyway. So the moment that somebody says, “Hey, um, I have an idea and I'm willing to contribute, not only the idea, but also an initial implementation,” you know, then we can discuss something then we can discuss not only the idea, but also how did you do that? How did he implement that?

That already brings you the discussion one step further because hey, what are the implications? or consequences of this choice? Are we doing it the correct way? So that really broadens the discussion a lot, actually.

A.J.

So the going back to the Maven versus a Gradle or Ivy, all these tools -

Kadi

You’re stuck on that huh?

A.J.

Yea yea…I think there's a perception that like Maven just move slower and that's what kind of bred some of these other tools. So are there things that those tools are doing right that you can see Maven gravitating towards one day? Or do you feel like Maven just got it really figured out.

Maarten

In the basics, I think Maven got it figured out, but that doesn't mean we're not moving anywhere. I mean, Gradle has some excellent features, excuse me, that Maven is currently lacking. But we are looking at it like, “It's actually a good idea. Maybe we should do something like that.”

Gradle has this demon, for instance, you know, to do the background process that just keeps on sitting there. We're working on having that in Maven as well. Gradle has a build cache. There's an effort currently running to actually bring that idea to Maven as well.

A.J.

That is one of my favorite things by the way. Especially if you have a huge build that takes them a while.

Maarten

I can see why it can save a lot of time and that, you know, we are looking at each other of course, and it's like, “Hey, that's a great idea. Maybe we can do something with that,” or, “Yeah, That wouldn't quite fit our model.”

So yeah, there is certainly a lot of movement in the Maven ecosystem. And I'm actually, it's funny that you mention that because next week I'll be at DevOxx France.. But probably when the episodes is being aired, it's already in the box. But I'm actually going to this because quite a few of the actual topics that are currently moving into Java community, like the demon, and like, I forgot the other one, nevermind. But a couple of these topics that are actually slowly making their way into Maven.

On the other hand, Gradle has the advantage that they can leverage from Maven because of Gradle under the hood still uses Maven Central. Uses for the IDL for project object model or POM.

Maven on the other hand, we cannot simply say, “Oh yeah, let's update the POM schema and other few elements there, drop a few there..” If we would do that, builds all around the world would fail because people are on an older version of Maven. So one of the things that's actually going to make it into Maven 4 for the first steps toward decoupling the POM.XML that we deploy onto Maven Central, from the one that's living in your Git repository, because then we can actually evolve to schema.

But that right now is really slowing us down. We simply can't change the schema because if we could do it, but then all the other tools would fail because everyone's using that schema. Right?

A.J.

So tell me more about that. So is that like an equivalent, for like npm, its the package not locked that you actually, when you pull them dependency pulling down versus the package that JSON just says, “here's what we'd like to be in there?”

I didn't quite get the disconnect from the POM in the repo versus the POM that's published.

Maarten

It's not exactly the same as the package for JSON, package log JSON. You typically have a POM.XML in your Git repository or subversion or whatever you're using. And as it is right now, if you, deploy artifacts in Maven Central, it's basically the same POM.XML, that goes from your Git repository into Maven Central.

Right? So if you would be using, let's hypothetical example, you'd be using Maven 4, which has a new version of the schema. So you dropped a few elements from your POM because for you, that works right in project. You're perfectly fine.

I, on the other hand, I'm using Maven 3 though, whatever. Grabbing your POM, that XML from Maven Central and my build tool, is like, “What’s that? There's no group idea over there. I can't use this.”

That's what we're decoupling from one another. So whatever you have in Git is not exactly the same as what moves to Maven central. So out what is in Maven Central will be backward compatible, like for ages, still allowing you to move on on your project and use the latest and greatest features.

A.J.

Okay. Interesting. Okay. I think I got it. So when you make a change like that, like how do you…. so there's a great concern to make sure you don't break the world builds, right? How do you actually go about testing something like that?

Maarten

Yeah, you definitely got to test things like these, because as I said, there's so many people relying on Maven and what not. So in fact, what we do in Maven itself, the core of Maven is actually relatively small. I think if you download it from the website, it's a 30 megabyte archive. Which is almost nothing these days. Right, because everything is in the plugins, but still that core of Maven is actuall- If you screw up anything there it's immediately affecting everybody.

So we have a very extensive suite of integration tests. It's a couple of thousands of projects that we actually built using Maven to verify if the outcome of that build is correct before saying, “Yes, this build is correct.” So we build it, we run those several thousand projects, inspect their outcomes. And when that's okay, then the build of Maven is completely done. Not when we just packaged it.

A.J.

Right.

Maarten

Only after building those thousands of projects. And that's really helpful for making sure that you didn't break anything.

A.J.

Yeah. And these, these projects are like, they're not actually part of your test suite, they're just reference projects?

Maaerten

No, these are actually our own test suite. So we handcrafted these projects like this is the particular thing that we want to prove that it works and that it keeps them working. And oftentimes when you have when you discover a bug in Maven, we ask you, “Can you reduce this into into a small reproducible example?” because that's gonna extend our test suite. That suite keeps on growing every time that we fix a bug, we try to craft this tiny project that just illustrates the bug and we audit our test suite, and then it becomes collective knowledge of what this is supposed to do.

AJ

What's your opinion on the Java derivative languages? Like Kotlin or Scala, all that. Do you have any opinions on those?

Maarten

Opinions, don't get me started. I used to- I have been using Scala a few years ago, actually in one of my consulting jobs. And it's, I have to say it's a very powerful language, but it's also, it's learning curve is steep. It's really, it takes time to actually learn and appreciate the features of the language.

And one of the things, we did a retro on the project and we were like yea Scala is powerful and what not, but we really should take care of not to overuse the language features because not everyone is at the same level there.

It's so hard. It's so tempting to be like, “Oh yeah, there's this powerful language feature. I'm going to pull that in.” And then somebody else will be looking at your code like, “Wow, is this Art or is this code? I don't know.”

But yeah, in the project we used Akka the actor framework and that's just a great fit to be using Scala anyway.

Funny thing is right now, I'm doing a project where we're building an Android app. So that's Kotlin and what I appreciate there is the learning curve is a lot less steep. So it's way easier to learn the language and to start benefiting from it. On the other hand, because it's so familiar to Java, it's tempting to write code that is just lacking a few semi-colons and a few curly braces.

You're basically copy paste in your Java approach to Kotlin and you're not fully leveraging all the functional goodness that the language gives you like Lambdas, enclosure or what not. So it's easier to learn and it's also easier to actually skipt he learning because it’s like, “Oh, it's so familiar, I already know this.”

I've already noticed and actually diving into the language. Oh, there's so much beauty in the language and, and that gives you so much more possibilities. So yeah. Yeah. It's an exciting time to be alive.

A.J.

Yeah, that is interesting. My take is like we use a lot Scala for a lot of our data engineering staff.

Spark. Right. It's like, Scala is very powerful, but you're right, there's all these these gotchas or, you know, things that you just like, why is this not working? Let me go fix that.

Kotlin, on the the hand, is just kind of fun. All right. The looseness of it a little bit, like it makes it fun. Like not writing final type variable name all the time.

Right over and over again. It's nice. Right? Yeah.

Kadi

Very cool. Yeah. I don't know if there's anything else you guys want to talk about.

Um, but I really appreciate you coming over and doing this for us.

Maarten

Not to worry. Yeah.

---

Continue to part two of this series.