Java evolves at a much faster pace than it used to do.
But not all of the projects we work on keep up with that pace.
I have projects on Java 8, 11 and 15 - and sometimes I want to play with early access builds of newer versions as well.
How to make sure I can build them without having to constantly switch Java runtimes?
Recently, the Maven community decided to push forward and start workingtowards a 4.0.0 release.
The first question after this announcement is of course: what can we expect Maven 4 to bring us?
A lot - and in this post, we want to highlight some of the features that we are particularly excited about.
Shipping a new release of software usually involves quite a few steps.
Depending on the type of software, this may be something you rarely do.
Thus, it often involves manual steps.
This is not necessary!
Maven has had its “Release Plugin” since approximately April 2007; yes, that’s over 12 years!
It has served both the Maven project and many other software projects.
When you’re writing Java applications, chances are you’re using Maven for dependency management.
It lets you declare the artifacts you need to build your application.
Those artifacts also depend on other artifacts.
This means you have transitive dependencies - dependencies you didn’t declare yourself but you need them anyway.
When using third-party components (be it open source or not), we all know it’s a good practice to keep your frameworks and libraries up to date.
This is also one of the spearhead in the OWASP Top 10 (2013 edition): A9 - Using Components with Known Vulnerabilities.
To help you assess your projects status with regard to this, OWASP.org developed the tool Dependency Check.
This tool is primarily intended code bases in Java, .NET, Ruby, Node.js, and Python.
Integration with various build tools is also provided for.
To start with a cliche: the Java ecosystem continues to develop at a high pace. Various open source frameworks releasing versions, sometimes even multiple versions at the same time. This may quickly turn into a risk But how to deal with it?
Basically, you have two options. We’ll take a typical Maven-project as an example, which uses Commons Lang 3. See the end of this post if you prefer Gradle over Maven.
When you’re building Java or JVM-based software, chances are these days you’ll be deploying it inside Docker. Chances also are you’re building it with Maven. Now how do you combine the two? Of course, you could plumb together some scripts for the platform of your choice, but there’s a few disadvantages to that. First of all, it makes you platform-dependant: your build may not work - or behave differently - depending on the platform where you’re building.