Maven JDK Toolchains

[Fernandoc4d (Fernando Javier)]

Hello community.
I’m building a Maven project, and I’m getting an error when I want to build with an older version of Java, which is necessary to build that application.
The solution in the log is to install the plugin that I attached in the attached image, but I see that this plugin does not exist.
Any other solution? Thank you,

[NotMyFault (Alexander Brandes)]

I’d recommend refactoring your maven project to a pipeline and specifying the maven and Java version you want to use. That way, you have full control over the Java and maven version to use.

[MarkEWaite (Mark Waite)]

@NotMyFault

I’d recommend refactoring your maven project to a pipeline and specifying the maven and Java version you want to use. That way, you have full control over the Java and maven version to use.

I agree with @NotMyFault that you should not use the Maven project type. The Maven project type in Jenkins is implemented by the Maven integration plugin. The Maven integration plugin includes the following warning text in its documentation:

The Jenkins project recommends that users transition from the Maven job type to use Pipeline jobs or freestyle jobs. Stephen Connolly describes many of the reasons in his 2013 blog post, “Jenkins’ Maven job type considered evil”. A revised version of that blog post is included here.

There are multiple ways to build a Maven project with Jenkins:

• Use a free-style project with a Maven build step
• Use a Maven-style project
• Use a Pipeline project with a shell, batch, or powershell build step that calls Maven

The first way runs the build as Maven intended. The second way adds a whole lot of hooks and can even modify the build in ways that Maven did not intend.

The first way requires that you configure stuff yourself. The second way tries to “guess” what you want and auto-configure it.

The first way is initially less user friendly, i.e. you have more UI to click through to get the full set of reports. The second way is initially more user friendly… but when things go wrong… well sorry out of luck.

If something goes wrong with the first way, worst case you add a shell build step above the Maven build step that just runs SET, trigger a build, login to the build agent, switch to the user the build is running as, apply the environment your SET build step output and then run the Maven command that the build’s console log captured. That will give you an exact reproduction of the Maven build and you can debug why your build is not working. When something goes wrong with the second way, well good luck. By all means try to do the same as you would for a freestyle project, but at the end of the day, there is no way you can replicate the injected hooks that Jenkins puts into your Maven build. You can get an approximate reproduction, and hey, that may just be enough to let you figure out what is wrong and fix your build… but there are cases where you cannot.

It is very attractive because is easy to configure (so users use it) and gives nice per-module reports. When it blows up, and it will blow up, it blows up big.

Refer to the video from Darin Pope for a tutorial

How to Configure Maven in Jenkins

[Fernandoc4d (Fernando Javier)]

Thanks @MarkEWaite Would this shell model be correct to start with?

#!/bin/bash

# Define variables
MAVEN_HOME=/path/to/your/maven/installation
JAVA_HOME=/path/to/your/java8/installation
PROJECT_REPO_URL=https://url/of/your/repository.git
REPO_BRANCH=branch-name

# Set up environment
export PATH=$MAVEN_HOME/bin:$JAVA_HOME/bin:$PATH

# Clone the repository
git clone $PROJECT_REPO_URL
cd repository-name

# Switch to the specified branch
git checkout $REPO_BRANCH

# Compile with Maven
mvn clean install

# If you want to run tests, you can add the following command
# mvn test

# The resulting .war files will be in the 'target' directory
# You can perform other actions according to your needs, such as deploying the application, etc.

# Finish and clean up
cd ..
rm -rf repository-name

# Exit successfully
exit 0