Recently, my good friend Richard Fichtner advised using the mvn dependency:analyze command to get rid of declared but unused dependencies: There is another use case for mvn dependency:analyze It can show you the dependencies you use in your code but have not declared in your pom.xml. This works because you have a transitive dependency on your classpath. Either don't use the dependency or declare it.[image or embed]— Richard Fichtner 💻☕ (@richard.fichtner.

I tweet technical content that I consider interesting, but the funny tweets are the ones that get the most engagement. I attended the JavaLand conference in March, stumbled upon the Gradle booth, and found this gem: There was a 'Moved Permanently' error fetching URL: 'https://twitter.com/nicolas_frankel/status/1638549568957861889' Of course, at some point, a fanboy hijacked the thread and claimed the so-called superiority of Gradle.

One of the Apache Maven committers recently wrote about their plans for Maven 5.

Last week, I described different techniques to fasten your Maven builds. Today, I’d like to widen the scope and do the same for Maven builds inside Docker. Between each run, we change the source code by adding a single blank line; between each section, we remove all built images, including the intermediate ones that are the results of the multi-stage build. The idea is to avoid reusing a previously built image. Baseline To compute a helpful baseline, we need a sample project.

Builds require a few properties, chief among them reproducibility. I would consider speed to be low on the order of priorities. However, it’s also one of the most limiting factors to your release cycle: if your build takes T, you cannot release faster than each T. Hence, you’ll probably want to speed up your builds after you’ve reached a certain maturity level to enable more frequent releases.

When your application goes beyond a dozen of lines of code, you should probably split the code into multiple classes. At this point, the question is how to distribute them. In Java, the classical format is the Java ARchive, better known as the JAR. But real-world applications probably depend on other JARs. This post aims to describe ways to create self-contained executable JARs, also known as uber-JARs or fat JARs. What is an executable JAR? A JAR is just a collection of class files.

Last week, I wrote a post that described how to hack the Maven dependency resolution system. I admit it was a dirty hack, it’s even in the post name. But I got it wrong. Thanks Stéphane Nicoll for pointing it out: There was a 'Moved Permanently' error fetching URL: 'https://twitter.com/snicoll/status/1338394993162145792' Even though I linked the documentation, I misread it. Here’s my mea culpa.

Logging is one of the fundamental components of any application which runs in production. Yet, between performance and logging in critical environments, I’d favor the former. For that reason, modern logging frameworks should implement at least two requirements: Async appenders: the write operation shouldn’t be blocking the execution of the programLazy computation: the framework doesn’t run expensive computations until they are needed - or never if that’s the case.

I like GitLab a lot. Yet, there’s no denying that GitHub has become the de facto standard to host Open Source projects. With GitHub Actions, it’s now possible to implement entire Continuous Integration pipelines without leaving GitHub. In this post, I’d like to highlight how to release Maven artifacts using GitHub Actions. Maven prerequisites Before creating the CI pipeline - and running it, it’s necessary to configure the underlying Maven project.

I’ve been recently developing a Spring Boot application, and to speed up my development speed, I added Developer Tools as a dependency. By default, classes loaded in the HotSpot JVM can be updated only if the later runs in debug mode, and only for changes regarding method implementation. This means adding an attribute to an class requires a full restart. DevTools is an improvement over that.

Spring Boot is a huge success, perhaps even more so than its inceptors hoped for. There is a lot of documentation, blog posts, and presentations on Spring Boot. However, most of them are aimed toward a feature, like monitoring or configuring. Few - if any of them, describe real-world practices. In this post, I’d like to highlight how to design a Spring Boot having multiple modules.

It sometimes happen that after a few years, an app is stable enough that it gets into hibernating mode. Though it’s used and useful, there are no changes to it and it happily runs its life. Then, after a while, someone decides to add some new features again. Apart from simple things such as locating the sources, one of the most important thing is to be able to build the app. Though it may seem trivial, there are some things to think about.

I recently got interested in Spring Social, and as part of my learning path, I tried to integrate their Github module which is still in Incubator mode. Unfortunately, this module seems to have been left behind, and its dependency on the core module uses an old version of it. And since I use the latest version of this core, Maven resolves one version to put in the WEB-INF/lib folder of the WAR package. Unfortunately, it doesn’t work so well at runtime.

Deploying on different environments requires configuration, e.g. database URL(s) must be set on each dedicated environment. In most - if not all Java applications, this is achieved through a .properties file, loaded through the appropriately-named Properties class. During development, there’s no reason not to use the same configuration system, e.g. to use an embedded h2 database instead of the production one.

Earlier on, Spring migrated from a monolithic approach - the whole framework, to a modular one - bean, context, test, etc. so that one could decide to use only the required modules. This modularity came at a cost, however: in the Maven build configuration (or the Gradle one for that matter), one had to specify the version for each used module.

There was a 'Moved Permanently' error fetching URL: 'https://twitter.com/nicolas_frankel/status/357158512205373440' This was my week’s hate, and I take full responsibility for every character in it. While that may seem like a troll, Twitter is not really the place to have a good-natured debate with factual arguments, so here is the follow up. Before going into full-blown rhetoric mode, let me first say that despite popular belief, I’m open to shiny new things.

Lately, I noticed my libraries weren’t published to Tomcat when I used a Maven project in Eclipse, even though it was standard war packaging. Since I mostly use Vaadin, I didn’t care much, I published the single vaadin-x.y.z.jar to the deployed WEB-INF/lib manually and I was done with it. Then, I realized it happened on two different instances of Eclipse and for the writing of Develop Vaadin apps with Scala, I used 3 different libraries, so I wanted to correct the problem.

This review is about Apache Maven 3 Cookbook by Srirangan from Packt Publishing.

Dear readers, In order to celebrate the release of Apache Maven 3 Cookbook, Packt Publishing contacted me in order to hold a contest to grab a free copy of the eBook! To be frank, I haven’t a clue toward organizing a contest so the first three who send me a mail at nicolas at frankel dot ch with the subject 'Apache Maven 3 Cookbook' will be sent the eBook for free. Don’t waste your time: on your mark, ready, go! And thanks Packt for these gifts.

This review is about Sonatype’s Maven: The complete reference by Tim O’Brien, John Casey, Brian Fox, Jason Van Zyl, Eric Redmond and Larry Shatzer. Disclaimer: I learned Maven from Sonatype’s site 3 years ago. I found it was a great tool to learn Maven. Now that I have a little more experience in the tool, I tried to write this review in an objective manner.

This review is about Packt’s Apache Maven 2 Effective Implementation by Maria Odea Ching and Brett Porter. Facts 12 chapters, 436 pages, 39.99$This book is intended for people that already have a good experience of Maven. The 'About Maven' part is as small as it can get, it is the opposite of what could be 'Maven for Dummies', where you learn to type mvn something.