DEV Community

Jean-François Lamy
Jean-François Lamy

Posted on • Edited on

Compiling Java 17 using Maven in an Azure DevOps Pipeline

Using ubuntu-latest machines in an Azure DevOps pipeline, there is currently no support for versions beyond 11. So using a Maven@3 task to compile using a newer version fails. The workaround is to use a container version of Maven.

jobs: # build uberjar - job: ${{ parameters.jobName }} pool: vmImage: ubuntu-latest container: maven:3.8.1-openjdk-17-slim variables: - name: JAVA_HOME_11_X64 value: /usr/local/openjdk-17 steps: - template: steps-prepare-maven.yml - task: Maven@3 displayName: build ${{ parameters.moduleName }} uberJar inputs: mavenPomFile: pom.xml mavenOptions: -Xmx3072m $(MavenOpts) javaHomeSelection: 'path' jdkDirectory: '/usr/local/openjdk-17' publishJUnitResults: true testResultsFiles: "**/surefire-reports/TEST-*.xml" effectivePomSkip: true goals: -P production -pl ${{ parameters.moduleName }} -am $(MavenOpts) -Dmaven.test.skip=${{ parameters.skipTests }} $(BuildGoal) 
Enter fullscreen mode Exit fullscreen mode

We are using openjdk-17 and explicitly using javaHomeSelection and jdkDirectory to set our JAVA_HOME to match where the container puts the JDK.

So why are we also defining the environment variable JAVA_HOME_11_X64, you ask? Well, I have reusable templates that are used outside the container setting. For example, the steps-prepare-maven.yml file is a template that creates a settings.xml file using the project secrets and updates the revision based on my build parameters - I also use it on Windows jobs. Such steps use the default version, Java 11. When running inside the container, the JAVA_HOME_11_X64 takes precedence and the Maven steps in the reusable templates work correctly.

This is extracted from a template file, replace the parameters with what you need.

Credit: sfragata's answer to a github issue got me started. Then I stumbled around until I could fix my included templates using the environment variable.

Top comments (0)