Tag: maven

Maven features I wish Gradle had: summary reports

Posted on by aalmiray

For quite some time now, Maven users have grown accustomed to seeing a summary report when a build is run. The report appears at two locations: at the beginning of the build where Maven shows the projects that participate in the current session (or Reactor if you prefer) which gives you a clue of how many projects, their packaging selection (jar, pom, etc), and perhaps more importantly, in which order they will be processed. The second location is at the end of the build where each project display its status (SUCCESS, FAILURE, SKIPPED) plus the time it took to execute Read More

Gum 0.7.2 delivers more bang for your buck

Posted on by aalmiray

A bang, like in JBang! That’s right, JBang is the new kid on the block in the Java command line tool space. Initially taking advantage of JEP-330 that enhances the Java launcher to support single source files, JBang builds on top of that idea and adds dependency resolution, JShell integration, launch executable JARs, launch scripts from trusted URLs, and a few other goodies. In other words, JBang is not constrained by JEP-330 (which requires Java 11) as it also let’s you run scripts with Java 8. Taking a hint from Gradle and Maven, JBang also adds a wrapper to help Read More

Gum 0.4.0 latest tricks

Posted on by aalmiray

Gum 0.4.0 is out and it comes with a few goodies! If you’re like me you may see yourself switching between Maven and Gradle projects, a lot. This constant switching makes it very likely that I’ll mess up the command invocation and send Maven goals to a Gradle project, or send Gradle tasks to a Maven project. This results in a wasted JVM iteration as the command fails. But what if there was a way to make it work given certain mappings? What if Maven’s compile goal could be translated into Gradle’s classes or viceversa? What if these mappings were Read More

Why do the Gradle/Maven wrappers matter?

Posted on by aalmiray

Indeed, why do these tool exist and why should I use them? After all installing Gradle or Maven is a simple task. Just download a ZIP file, configure an environment variable and voilà! Or use a package manager such as SdkMan! Well to understand these questions we must travel back in time, to a moment when Gradle was just getting started and Maven 3 was just a few months of being released. Gradle’s inception happened sometime in late 2007. In comparison Maven was at 2.0.7 or 2.0.8 (see history of Maven release notes). Everyone knew Maven at that time but Read More

Gum: the Gradle/Maven wrapper

Posted on by aalmiray

I’m happy to announce the immediate availability of Gum, a Gradle/Maven wrapper written in Go. Gum is inspired on the popular gdub script by Doug Borg, which was ported to Go by Sten Roger Sandvik some time ago. The main difference from Sten’s version is that Gum also supports the Maven wrapper, coming up as part of Maven core 3.7! The basic idea behind Gum is to prefer the tool wrapper over the plain tool, if the wrapper is configured. It also allows you invoke the build tool from any place withing the project’s codebase. There are a few additions Read More

Publishing artifacts to Maven Central with Bintray & Gradle

Posted on by aalmiray

Recently I joined a conversation on Twitter where the OP complained to spending hours to get a brand new computer setup to publish artifacts to Maven Central. The issue stemmed from having PGP signature files moved from one location to another. There are other issues that may arise when uploading artifacts to Maven Central, specially when doing it for the first time. The rules for publishing artifacts are stated here. A common mistake is to omit one of the required POM elements, which will likely trigger a series of back-and-forth revisions until you get it right. This can be frustrating Read More

Announcing the PomChecker project

Posted on by aalmiray

I’m happy to announce the immediate availability of the PomChecker suite! What is it you ask? It’s a small set of utilities to verify that a POM or BOM file complies with the minimum requirements for being uploaded to Maven Central. I wish an utility like this existed years ago when I started publishing artifacts to Maven Central. It took me a few tries in the beginning to get the POM files just right. Recently I’ve seen other developers struggling with these rules as well. Hopefully these utilities can help them and others get on the road much faster. There Read More

Detecting duplicate dependencies in Maven

Posted on by aalmiray

In late March 2020 I ran a quiz on Maven Dependency Resolution which turned out to be an eye opener for some people (including myself!). You can read the whole questionnaire, results, and analysis here. One of the surprising results was found in the very first question, a rather innocuous one but it resulted in a major stumbling block for 2/3 of respondents! Here’s the question What’s surprising is that only 36% people chose the correct answer and a similar percentage chose the “Build error” option because clearly duplicate dependencies ought to cause a build error, right? Wrong! Maven does Read More

Announcing the Gradle Enforcer Plugin

Posted on by aalmiray

Inspired by the popular Maven Enforcer plugin I’m happy to announce that its Gradle counterpart has been released, say hello to the enforcer-gradle-plugin! The behavior provided by Gradle Enforcer plugin is very similar to what the Maven Enforcer plugin provides, in the sense that rules will be executed during a particular phase of the build; any rule violations result in a build failure. Rules are typically setup to check for preconditions and requirements. The Maven Enforcer plugin provides a set of core rules and extra rules. In turn, the Gradle Enforcer plugin provides a similar set plus a few rules Read More

Maven Dependencies Pop Quiz – Results

Posted on by admin

A couple of weeks ago I posted a link to a pop quiz regarding dependency resolution in Apache Maven. 509 brave souls took the challenge; now is the time to share the results. The quiz is comprised of 14 questions split between 3 sections based on context: A single project A project with a parent POM A project with a BOM Each question revolves around figuring out what would be the selected version of a particular dependency, in this case Guava, because as many developers know, whenever there’s a classpath issue Guava is always to blame (What?!) To be fair, Read More

ˆ Back To Top