I recently upgraded to Maven 3.5 and Java 8 on my dev environment as I have upgraded my company's Maven-managed application from Java 6 to Java 8 on our 'master' environment. Unfortunately I have run into difficulty using this setup against older versions of the application that are set to compile against Java 6, as Maven tries to compile against the version of Java it is currently running against (in my case Java 8). I have looked into using Maven Toolchains (details here), but this won't work because a couple of our Maven plugins are not 'toolchain aware', such as the AspectJ Maven plugin, which therefore tries to compile the project against Java 8 and thus I get compile errors. I think I will have to resort to running two Maven installations side-by-side and just switch between the two. But before I do that, does anybody know of any potential solution to such a problem?
Thanks in advance
Related
I heard that it is possible to use 2 different version of JDK in Eclipse (Oxygen) but I cannot figure out how.
I am trying to use JDK 1.8 for project source code, but JDK 11 for Cucumber tests.
Is this possible to do?
I need to run a java application in my gradle build. That application uses reflection, and will not run in java 11. So my gradle JVM needs to be java 10. (A dead end, I know, that's what I'm working on)
But my build configurations currently use the javafx plugin, and all the versions on plugins.gradle.org are built with Java 11 classes, so the plugin won't work with Java 10.
I compiled the javafx plugin for Java 10 with sources from github, but the plugin is configured to use java 11 repositories, so I'd need to figure that out and replace them.
It would save me enormous hassle if there was already a javafx plugin that works with Java 10.
I am currently implementing a new Maven Plugin and I would like to use Java 11 for compilation and execution.
However, I would like my Maven plugin to be used by most of our projects. Some of them are running in Java 8, some in Java 11.
Is it mandatory to use Java 8 in my Maven Plugin if I want it to be included in other project ? Is there a way to implement it in Java 11 and make it available for Java 8 project ?
As quite often: it depends. And with Maven Java is used at different levels, so this requires a bit of explanation:
Are you going to use Java 9+ specific features/APIs?
If not, you can build your project with Java 11, but you need to add <release>8</release> to the maven-compiler-plugin to ensure the code is Java 8 compatible.
If you do plan to use Java 9+ features/APIs, add <release>11</release> to the maven-compiler-plugin. Now you require your users that they run Maven with at least Java 11 (which is not a problem, even Maven 3.0 runs fine with Java 14-ea).
Even though Maven runs on Java 11, your users can still create Java 8 compatible projects (just like the "if not, ..." from the first bullet), but most are used to run and build with Java 8.
we have a Jenkins job which is/was configured to use JDK7. Upon inspecting the logs, i noticed following ERRORs:
ERROR: Invalid project setup: jenkins/security/MasterToSlaveCallable : Unsupported major.minor version 52.0
ERROR: [JENKINS-18403][JENKINS-28294] JDK 'JDK 1.7.0_45' not supported to run Maven projects.
ERROR: Maven projects have to be launched with a Java version greater or equal to the minimum version required by the master.
ERROR: Use the Maven JDK Toolchains (plugin) to build your maven project with an older JDK.
ERROR: Retrying with slave Java and setting compile/test properties to point to /usr/java/jdk1.7.0_45/.
After some googling it seems that there is some interaction between the Job and Jenkins itself. Since Jenkins is started with JDK8 and the Job with JDK7 it seems to produce this ERROR. The build is OK, because Jenkins then proceeds to build with JDK8. But we actually want this built with 1.7.
So the question is:
If we start Jenkins with JDK8, how can i get the Jobs to compile with JDK7 without this error?
this is apparently a technical limitation of Jenkins plugin Maven Integration.
Because java serialized classes are exchanged between Jenkins master and Maven Jobs it is required that the JVM used to launch Maven is superior or equal to the version of Java for which Jenkins Master is built for.
I suspect that you have a Jenkins version too recent, requiring a JDK version >= 8.
As the required version was 7, you could either use java 7 or 8 - or even 9. So your build succeeded with Java7, even if your Jenkins was started with Java8.
You can either downgrade your Jenkins installation, or move all your builds to Java8.
Cheers
For using Java 1.7 on Jenkins >= 2.54 you need to transform the Maven project in a Free-style project. In the Free-style project you can specify the JDK version. This is because starting from version 2.54, Jenkins was upgraded to use Java 8.
From Jenkins release notes:
Using the Maven project type with Java 7
Users with jobs configured with the "Maven project" type may not be
able to use Java 7 for their Maven jobs. The correct behavior is not
guaranteed so proceed at your own risk. The Maven Project uses Jenkins
Remoting to establish "interceptors" within the Maven executable.
Because of this, Maven uses Remoting and other Jenkins core classes,
and this behavior may break an update
You can also see here how to create a Free-style project
As you might probably know Jenkins >= 2.54 requires Java >= 8 thus Maven jobs must be launched with Java >= 8
Besides that the Error message is guiding you with:
Use the Maven JDK Toolchains (plugin) to build your maven project...
Using that plugin would probably help you to run your jenkins job using Java 8 and also compile your project files using Java 7.
I resolved my problem this way some years ago.
You can see more details on this Answer.
The interaction is based on that Jenkins will try to be informed about finishing single modules and if there are artifacts being created and some other stuff. This is handled by a EventSpy implementation in Jenkins. That can cause issues like this.
I'm maintaining a parent pom for my team which will provide the latest compatible version of various maven plugins per the JDK that the project uses. Sometimes if a project utilizes an older version of Java (like 1.5) maven will fail due to a plugin requiring a newer version. Is there a way to get a map of a given plugin and see what the minimum java version is for said plugin? I was thinking there was some sort of report or something that would show me that, but I'm not seeing anything.
What about: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html Apart from that on every plugin page you can find the goals page which contains the information you need. One more thing if you are using not the most uptodate versions all older versions pages are available where you can look at which version which JDK versions uses. It shouldn't be problem to write some kind of script to programmatically extract the information of the older plugins. The above site contains the informations of the uptodate plugins.
Apart from that plugin version selection basead on JDK version is not a good idea. The plugins have only a minimum version for JDK they need to run with. Apart from that they run on all versions (already on JDK 9 with one exception)...Furthermore plugins might require a minimum Maven version to run with which is either Maven 2.2.1 or Maven 3.0+ which shouldn't a problem.
You should define your plugins versions simply based on problems you might have but i would recommend to keep uptodate with your plugins.
If you need running you build with JDK 6 for example, but you use Maven 3.3.X which needs JDK 7 to run you can achieve this by using toolchain to handle this situation.
In theory this shouldn't be an issue. Maven will use the Java version you run it with, so the plugin's dependency will be satisfied, independent of the project's language level. Just make sure your devs are using a current version.
Example: running Maven with Java 8 will satisfy the dependency of a Plugin that requires Java 8, independent of the project's source and target level.
(With dependencies it's more complicated, I am afraid, but since you are not actually coding against your plugins, you should be fine)