• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Maven compiler settings for Java 10 or higher

 
Ranch Hand
Posts: 143
6
IntelliJ IDE Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I set compiler version in the maven pom.xml file like this:



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 ?
 
Saloon Keeper
Posts: 12488
269
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have something a bit different. Is mine correct?

 
Carey Brown
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a maven'ism that would allow you to specify the Java version via an environment variable?
 
Carey Brown
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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


ANSWER
 
Marshal
Posts: 71042
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question too difficult for “beginning”. Moving to our Maven forum
 
Stephan van Hulst
Saloon Keeper
Posts: 12488
269
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 12488
269
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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:

Or like this:

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:

The POM of one of my projects looks like this:

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
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 22040
113
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@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:

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
Saloon Keeper
Posts: 12488
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 12488
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 12488
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 12488
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, I see you named the root POM root-pom.xml. That won't work. Unprocessed POMs are ALWAYS named pom.xml.
 
Carey Brown
Bartender
Posts: 7431
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

And thanks for all your help. This will clean up a lot of things in my development directory.
 
Stephan van Hulst
Saloon Keeper
Posts: 12488
269
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

Then, in a child project you could do:

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic