Maven compiler settings for Java 10 or higher

[Tom Joe]

I set compiler version in the maven pom.xml file like this:

<properties>    <maven.compiler.source>1.8</maven.compiler.source>    <maven.compiler.target>1.8</maven.compiler.target> </properties>

Which version do I set for Java 10 and above ? Is it 10 or 1.10 ? Have the tags changed for Java 10 and above ?

[Stephan van Hulst]

I'm not sure if Maven still accepts the old format for versions 9 and higher, but it will accept the new format for versions 5 and higher, so just always use the new format:
<!-- Use any of the following --> <maven.compiler.source>5</maven.compiler.source> <maven.compiler.source>6</maven.compiler.source> <maven.compiler.source>7</maven.compiler.source> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.source>9</maven.compiler.source> <maven.compiler.source>10</maven.compiler.source> <maven.compiler.source>11</maven.compiler.source> <maven.compiler.source>12</maven.compiler.source> <maven.compiler.source>13</maven.compiler.source>

[Carey Brown]

I have something a bit different. Is mine correct?

 <properties>    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>    <java.version>12</java.version>  </properties>  <build>    <plugins>      <plugin>        <groupId>org.apache.maven.plugins</groupId>        <artifactId>maven-compiler-plugin</artifactId>        <version>3.8.0</version>        <configuration>          <source>${java.version}</source>          <target>${java.version}</target>        </configuration>      </plugin>

[Carey Brown]

Is there a maven'ism that would allow you to specify the Java version via an environment variable?

[Carey Brown]

Carey Brown wrote:Is there a maven'ism that would allow you to specify the Java version via an environment variable?

ANSWER

[Campbell Ritchie]

Question too difficult for “beginning”. Moving to our Maven forum

[Stephan van Hulst]

Carey Brown wrote:I have something a bit different. Is mine correct?

Sure it's fine. You just declared a project variable to hold the java version and used it to set both the source and target versions of the compiler. Note that a lot of plugin settings have a so called "user property" alias that allows you to set the property in the <properties> element without having to declare the <plugin>. I prefer the user property because it's less verbose.

Is there a maven'ism that would allow you to specify the Java version via an environment variable?

You've found an answer, and though I haven't reviewed it yet I can already tell you this is a really bad idea. Maven builds really really really need to be reproducible. If you check out a project 5 years after it's been installed at a customer, you still want to be able to build it without fiddling with it. Environment variables will completely mess that up.

[Carey Brown]

Stephan van Hulst wrote:

Carey Brown wrote:I have something a bit different. Is mine correct?

Sure it's fine. You just declared a project variable to hold the java version and used it to set both the source and target versions of the compiler. Note that a lot of plugin settings have a so called "user property" alias that allows you to set the property in the <properties> element without having to declare the <plugin>. I prefer the user property because it's less verbose.

I'm not really well versed in Maven so when I ran across the plugin example I started using it. I wasn't aware of the properties short cut. Is there any advantage to using the plugin approach? Where do I find out about other property short cuts I may be missing?

Is there a maven'ism that would allow you to specify the Java version via an environment variable?

You've found an answer, and though I haven't reviewed it yet I can already tell you this is a really bad idea. Maven builds really really really need to be reproducible. If you check out a project 5 years after it's been installed at a customer, you still want to be able to build it without fiddling with it. Environment variables will completely mess that up.

Yes, I read that warning in the answer link. If I was still writing commercial code I'd agree with you 100%, but I'm retired and I'm dealing with a 100 small to middlin sized personal projects that I'm trying to keep in sync with the Java version I'm using (i.e. the latest). I still have some projects hard wired for Java 8 but mostly I want them all to use the latest. I don't know if there's a better way of dealing with this.

[Stephan van Hulst]

Carey Brown wrote:Is there any advantage to using the plugin approach?

Some plugin settings don't have a user setting. It's also appropriate to use the <plugin> approach when you want to configure a specific execution of a plugin.

Where do I find out about other property short cuts I may be missing?

Find the documentation page for a plugin's goal and it will list the goal's settings as well as possible user property aliases for it. For instance, take a look at the compiler:compile goal here. You will see that it has several parameters that also mention what the associated user property. For example, the showWarnings parameter says that it has an associated user property maven.compiler.showWarnings, meaning you can either configure it like this:
<plugin>  <artifactId>maven-compiler-plugin</artifactId>  <configuration>    <showWarnings>true</showWarnings>  </configuration> </plugin>
Or like this:<properties>  <maven.compiler.showWarnings>true</maven.compiler.showWarnings> </properties>

I still have some projects hard wired for Java 8 but mostly I want them all to use the latest. I don't know if there's a better way of dealing with this.

Well what I do is have a root POM that I use as a parent for all my projects:
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (C) Stephan van Hulst.   -   - This Source Code Form is subject to the terms of the Mozilla Public   - License, v. 2.0. If a copy of the MPL was not distributed with this   - file, You can obtain one at https://mozilla.org/MPL/2.0/. --> <project  xmlns              = "http://maven.apache.org/POM/4.0.0"  xmlns:xsi          = "http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" >  <modelVersion>4.0.0</modelVersion>  <groupId>nl.nibsi</groupId>  <artifactId>root-pom</artifactId>  <version>0.1.0</version>  <packaging>pom</packaging>  <name>Root POM</name>  <developers>    <developer>      <id>shwvanhulst</id>      <name>Stephan van Hulst</name>      <url>https://github.com/shwvanhulst</url>      <email>[e-mail]</email>      <timezone>Europe/Amsterdam</timezone>    </developer>  </developers>  <properties>    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>  </properties>  <build>    <pluginManagement>      <plugins>        <plugin>          <artifactId>maven-antrun-plugin</artifactId>          <version>1.8</version>        </plugin>        <plugin>          <artifactId>maven-assembly-plugin</artifactId>          <version>3.2.0</version>        </plugin>        <plugin>          <artifactId>maven-clean-plugin</artifactId>          <version>3.1.0</version>        </plugin>        <plugin>          <artifactId>maven-compiler-plugin</artifactId>          <version>3.8.1</version>        </plugin>        <plugin>          <artifactId>maven-dependency-plugin</artifactId>          <version>3.1.1</version>        </plugin>        <plugin>          <artifactId>maven-deploy-plugin</artifactId>          <version>2.8.2</version>        </plugin>        <plugin>          <artifactId>maven-ejb-plugin</artifactId>          <version>3.0.1</version>        </plugin>        <plugin>          <artifactId>maven-ear-plugin</artifactId>          <version>3.0.2</version>        </plugin>        <plugin>          <artifactId>maven-install-plugin</artifactId>          <version>2.5.2</version>        </plugin>        <plugin>          <artifactId>maven-jar-plugin</artifactId>          <version>3.2.0</version>        </plugin>        <plugin>          <artifactId>maven-javadoc-plugin</artifactId>          <version>3.1.1</version>        </plugin>        <plugin>          <artifactId>maven-plugin-plugin</artifactId>          <version>3.6.0</version>        </plugin>        <plugin>          <artifactId>maven-project-info-reports-plugin</artifactId>          <version>3.0.0</version>        </plugin>        <plugin>          <artifactId>maven-release-plugin</artifactId>          <version>2.5.3</version>        </plugin>        <plugin>          <artifactId>maven-resources-plugin</artifactId>          <version>3.1.0</version>        </plugin>        <plugin>          <artifactId>maven-site-plugin</artifactId>          <version>3.8.2</version>        </plugin>        <plugin>          <artifactId>maven-surefire-plugin</artifactId>          <version>2.22.2</version>        </plugin>        <plugin>          <artifactId>maven-war-plugin</artifactId>          <version>3.2.3</version>        </plugin>      </plugins>    </pluginManagement>  </build> </project>
The POM of one of my projects looks like this:
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (C) Stephan van Hulst.   -   - This Source Code Form is subject to the terms of the Mozilla Public   - License, v. 2.0. If a copy of the MPL was not distributed with this   - file, You can obtain one at https://mozilla.org/MPL/2.0/. --> <project  xmlns              = "http://maven.apache.org/POM/4.0.0"  xmlns:xsi          = "http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" >  <modelVersion>4.0.0</modelVersion>  <parent>    <groupId>nl.nibsi</groupId>    <artifactId>root-pom</artifactId>    <version>0.1.0</version>  </parent>  <groupId>nl.nibsi.require</groupId>  <artifactId>require-core</artifactId>  <version>0.1.0</version>  <name>Require</name>  <licenses>    <license>      <name>Mozilla Public License Version 2.0</name>      <url>https://www.mozilla.org/en-US/MPL/2.0/</url>    </license>  </licenses>  <scm>    <connection>scm:git:https://github.com/shwvanhulst/require</connection>  </scm>  <properties>    <maven.compiler.source>13</maven.compiler.source>    <maven.compiler.target>13</maven.compiler.target>  </properties>  <dependencies>    <dependency>      <groupId>org.hamcrest</groupId>      <artifactId>hamcrest</artifactId>      <version>2.2</version>    </dependency>  </dependencies>  <repositories>    <repository>      <id>central</id>      <name>Central Repository</name>      <url>https://repo.maven.apache.org/maven2</url>      <snapshots>        <enabled>false</enabled>      </snapshots>    </repository>    <repository>      <id>shwvanhulst</id>      <name>My GitHub Repository</name>      <url>https://maven.pkg.github.com/shwvanhulst/artifacts</url>      <snapshots>        <enabled>false</enabled>      </snapshots>    </repository>  </repositories> </project>
As you can see, I configured my target version at the project level, but you can also move it to the root POM and it will be the same for all your projects that inherit from your root POM.

[Carey Brown]

Thank you. That was a wealth of information. I like the parent POM idea, I'll have to take some time to study it. Looks like I don't need the verbose <plugin> stuff at all, which will help.

[Rob Spoor]

Tom Joe wrote:Which version do I set for Java 10 and above ? Is it 10 or 1.10 ? Have the tags changed for Java 10 and above ?

Java 8 was the last one with an internal version that started with 1. So after 1.8 came 9, not 1.9.

[Carey Brown]

@Stephan,

I'm in the process of upgrading to jdk-14. I'm pretty much there but I thought now would be a good time to try out your parent pom approach.

I have the following development tree:

D:
  \srcjava
    \Root
      \root-pom.xml (copied from your post)
    \Project
      \pom.xml (tweaked based on your post. can't find root-pom)
      \src ...

I'm guessing that Root needs its own pom.xml that somehow gets root-pom.xml  into my repository (not sure how to do that). I'm also not sure of how to use the groupId to give it a name that my Project pom can find.

[Stephan van Hulst]

You run "mvn install" on your root project before you build your child project.

Check out the Maven Introduction to the Build Lifecycle. It's a good read.

[Stephan van Hulst]

Note that the group ID doesn't need to be the same. A parent can be referenced to by a different group ID.

However, if your parent has the same group ID as the child project, the child doesn't need to declare its own group ID, it will just inherit the parent's group ID. The same is true for the project version. This can be useful if you want to make a parent POM for a whole collection of projects that are related.

[Stephan van Hulst]

And a final remark, if you know for certain that the child project will always be relative to the parent project in some consistent way, you can declare the parent POM's path in the <relativePath> element inside the <parent> element. That way you don't need to install the parent project manually before you install the child project. By default, this element has the value "..", so child projects that are in a child folder under the parent project folder will automatically pick up the parent POM XML path without you having to declare it.

I didn't do this for my root POM though, because it lives in a separate repository. In general, it's a good idea for project parents though.

[Stephan van Hulst]

Oh, I see you named the root POM root-pom.xml. That won't work. Unprocessed POMs are ALWAYS named pom.xml.

[Carey Brown]

I think I've got it. There were a number of steps I was missing.
Needed a project for Root.
Rename root-pom.xml --> pom.xml

I also have these dependencies in my project. Can they be put in the root as well?

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.38</version>
    </dependency>
    <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j -->
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.17</version>
    </dependency>
  </dependencies>

And thanks for all your help. This will clean up a lot of things in my development directory.

[Stephan van Hulst]

Don't use the <dependencies> element in POM projects. Instead, use <dependencyManagement>. That way you can configure fixed versions (and maybe scopes as well) for dependencies that you use often, without actually forcing child projects to use those dependencies.

For instance, in a parent POM you could do this:
<dependencyManagement>  <dependencies>    <dependency>      <groupId>jakarta.servlet</groupId>      <artifactId>jakarta.servlet-api</artifactId>      <version>4.0.3</version>      <scope>provided</provided>    </dependency>    <dependency>      <groupId>org.junit.jupiter</groupId>      <artifactId>junit-jupiter-api</artifactId>      <version>5.0.6</version>      <scope>test</provided>    </dependency>  </dependencies> </dependencyManagement>
Then, in a child project you could do:
<dependencies>  <dependency>    <groupId>org.junit.jupiter</groupId>    <artifactId>junit-jupiter-api</artifactId>  </dependency> </dependencies>
The child would use the JUnit Jupiter API with the appropriate version and scope, but it wouldn't use the Jakarta Servlet API. Don't quote me on the scope though, I've had wonky behavior where the scope was always inherited as compile.

In general, I advise using dependency management and plugin management at the project parent level, not the root pom level, because otherwise your root will be overflowing in no time.