Author: aalmiray

Publishing to Maven Central using Apache Maven

Posted on by aalmiray

Last week JFrog announced changes to its Bintray & JCenter services which will eventually lead to these services being discontinued by February 2022. I’ve been a happy Bintray user since the early days. Their services make uploading archives and making them available to the public a snap. Syncing those artifacts from JCenter to Maven Central can also be automated, simplifying the full release process. Previously I blogged about the options available to Gradle projects for publishing to Maven Central via Bintray. I’m saddened by the recent news of Bintray riding into the sunset, I’ll miss it dearly. And like many Read More

Building a layered modular Java application? Watch out for these!

Posted on by aalmiray

Recently I’ve been experimenting with building layered modular Java applications with Layrry, a launcher and Java API for executing modularized Java applications. It so happens that version 1.0.0.Alpha1 was just released a couple of weeks ago, making it easier for anyone to give it a try. The base concept of Layrry is to organize your code in such a way that modules are grouped in a series of layers, enabling isolation between said layers as there’s a single classloader per layer, thus allowing conflicting modules (such as binary incompatibilities between classes) to be used within the same application. Module layers Read More

Layrry 1.0.0.Alpha1 has been released!

Posted on by aalmiray

A brand new day brings a brand new release: I’m ecstatic to announce that Layrry 1.0.0.Alpha1 has been released! You can find all artifacts at Maven Central, Bintray, download them from Layrry’s releases page, or build it yourself by cloning https://github.com/moditect/layrry.git and following the build instructions found in the README, basically mvn install (yup, install is needed in this case, you can skip the clean). What’s more, you can also install Layrry directly from SDKMAN! as it’s now available as a candidate. 🤩😱😍🥳 #Layrry at @sdkman_ pic.twitter.com/Kgu1BrsCaO — Andres Almiray (@aalmiray) January 30, 2021 What’s all the fuzz about Layrry Read More

Releases posted in 2020

Posted on by aalmiray

2020 was quite the year to say the least. The news cycle was underwhelming all year round. I must confess there were days when it was quite difficult to concentrate and couldn’t get anything done. I count myself among the lucky ones that were able to work from home since day one and didn’t get sick though I can’t say the same for friends and family, some got sick (most recovered) but tragically a few dear friends left before their time. Despite all the ups and downs I managed to post some releases during the year, as a matter of Read More

Ikonli 12.0.0 Released!

Posted on by aalmiray

I’m ecstatic to announce that Ikonli 12.0.0 is finally available for general consumption! Ikonli is the best way to add spice and character to JavaFX and Swing applications alike via configurable icons. Ikonli provides icon packs for popular icon sets such as FontAwesome, Material Design, Weather icons, and more. This release increases the number of icons packs from 31 to 55! That’s a lot of icons to choose from! There’s no need to hunt down icons on the web, it’s likely Ikonli provides just what you require. But in the case that wasn’t true Ikonli is extensible, allowing you to Read More

Maven: verify or clean install?

Posted on by aalmiray

This is it. After months of tweeting memes about mvn clean install I decided to get some numbers to see how performance would be affected when switching from one command to the other. But first a bit of history. Like many developers when faced with building a Maven project the first reaction is to invoke mvn clean install, after all you find that instruction in almost every README or BUILD file, so why question it? It does not matter if the project is single or contains multiple modules, the instruction is the same. As a matter of fact when the Read More

Gradle POMs revisited

Posted on by aalmiray

Close to two years ago I posted my thoughts on introducing a Maven-like structure for organizing and building Gradle projects. I dubbed those ramblings The Gradle POM and The Gradle SuperPOM. In truth the latter is a misnomer, instead it should had been “The Gradle Parent POM”. These posts served as an introduction to a new project I had been working on: the Kordamp Gradle Plugin suite. The original goal for this project was to bring order to chaos found in the dozens of Open Source projects I actively maintain. Before Kordamp began, all these projects relied on the tried Read More

Maven features I wish Gradle had: inlined plugins

Posted on by aalmiray

Since the early days of Maven the development team recognized that they couldn’t (and shouldn’t) provide a solution for every problem we as consumers may face with our builds. In order to cater for our every whim and emerging requirements the Maven build tool added a pluggable mechanism to provide behavior as needed, and thus Maven plugins were born. Maven plugins are typically configured inside a <build> block found in the pom.xml file, which lets them contribute goals that may bind to lifecycle phases by default, or just providing goals that you can invoke at any time. But what if Read More

Gum 0.8.0 is out!

Posted on by aalmiray

Whoa, 2 Gum releases in the same month? I’m having so much fun working with and on Gum that I just couldn’t resist posting another release. Last time I mentioned that Gum is capable of launching JBang with explicit and implicit targets; in the case of implicit a strict file order was to be followed: .java, .jsh, and .jar. Well no more, Gum 0.8.0 let’s you configure the resolution order as you deem necessary. The configuration may be per directory (project) or global. Which brings me to the second major feature added to this release, how do you know which Read More

Maven features I wish Gradle had: override task properties

Posted on by aalmiray

It’s no secret that one of the most common properties ever set on a Maven build is -DskipTests which as the name implies, instructs Maven to skip running tests. As a matter of fact that property is read by the maven-surefire-plugin to figure out if it should run tests or not. As it turns out there’s a separate property named skip that instructs Maven to skip compiling and running tests. If you’re curious and peek at the documentation you may notice that the field/property names for skipTest match but for skip you’ll find a property named maven.test.skip. As it happens, Read More

ˆ Back To Top