I have a pom including some plugins. The project's sources are java 17 and as such, the maven build is run with a jdk17+. Now, one of the plugins bound to the site lifecycle, let's say plugin P1, is older and it doesn't work with java versions newer than 9 ( because of some deprecated API that is no longer present in the jdk)
My question is: is it possible to somehow configure in the pom that some plugins should be run with a different java version?
My intention is to run the plugin as it is, not wanting to re-write it or modify it in any way.
I know about maven toolchains, but I don't see how this applies, as that configures the jdk version for all plugins.
Depending on the plugins and the context, you may solve the problem by using separate Maven runs, i.e. run
mvn clean install
with JDK17 and then run mvn some:plugin with a different JDK.
Related
The solution which needs bootstrapping is supplied as java code. Absolutely sure that this is necessary.
Receivers of the solution are guaranteed to have a suitable JDK
However, receivers of the solution are unable to install Maven (they don't know how to and cannot be taught)
My idea is to include some sort of Maven with the project, such that can be set up in a script like so:
set up maven repo as a folder under the solution folder (using relative reference)
set up anything else maven needs (don't know what, exactly)
call /path/to/maven/mvn compile -f /path/to/oneAndOnly/pom.xml
java /target/MySolutionClas
I am aware of: https://dzone.com/articles/embedding-maven but it gets confusing when he talks about configuring the portable maven into the pom.xml - wait, how is that pom.xml going to mean anything if maven is not configured yet?
(PS: I mean no disrespect to the author. I probably got it all wrong)
One could include a shell script that would setup maven if it is not already present.
The same for building and packaging encapsulating the complexities of the setup to just runing a couple of scripts.
Maven Wrapper aims to do just that, similar to the gradle wrapper seen in many gradle projects.
Running the wrapper goal of the maven wrapper plugin will generate a mvnw script in your project that can be run in place of a globally installed mvn command.
It's part of the maven 3.7.0 release, and documented more fully here: https://maven.apache.org/plugins/maven-wrapper-plugin/index.html
See https://github.com/takari/maven-wrapper for maven < 3.7.0
So here is a quick rundown of my situation:
I have two Java projects: one in Java 8 (so not modular) and one in Java 11 that is modular.
The modular/not-modular issue may not be relevant but for the sake of clarity, I've stated it.
For reference, the Java 8 is a game library I made, and the Java 11 is the game implementation I'm making.
I need to reference the Java 8 library from my Java 11 game project.
Both projects are Maven projects, and I have my dependency defined in my game's POM file.
I'm using latest version of Eclipse (2020-03 4.15.0) and Maven 3.6.3 with Java version 11.0.7 OracleJDK.
My Problem:
My understanding is that my Java 8 library project becomes an automatic module. Adding it into my Java 11 game project module-info file works (with a warning about the name being unstable, but no issue) and I can compile my game project code with no issues in Eclipse.
When I attempt to run the game, I get Module <my-library> not found, required by <my-game>. Now, since Maven is managing the dependencies, it should just work.
How can I get my game to run?
I Can Fix It Three Ways...
First I can simply manually add the library project's JAR file (in it's target folder) to the Run Configuration module-path of my game project.
Second, I can delete the library project from my workspace. This means Maven then goes and gets the JAR from the local m2 repo (it's been installed with mvn install). In this situation Maven DOES automatically add the JAR to the Run Configuration module-path correctly.
Third, I can change the version of the library project in it's POM file and like option two, this means it no longer satisfies the dependency and Maven then looks for the JAR in the local m2 repo.
But...
All three of these options seem to me like they should be unnecessary. This feels like a bug with Maven failing to add the in-workspace project dependency to the module path in the Run Configuration in Eclipse.
To be fair, it is a Maven Eclipse plugin feature that automatically detects when one of the in-workspace projects is a dependency and uses that "live" version instead of the m2 repo version. This is very handy for these situations where development on a library is happening in parallel.
But until this bug is fixed (or unless it's not a bug and I'm missing something), this caused me a ton of frustration. I've posted this in hopes of helping anyone else who may be facing the same issue.
As example, i have program with version 0.0.1. Maven must create separate folder for it - "target/0.0.1/" instead of "target/". It must be done for version "0.0.2", "0.0.3", etc.
I use Eclipse & it's Maven:
Version: Oxygen.3a Release (4.7.3a)
Build id: 20180405-1200
JDK 1.8.0_172
Maven doesn't work that way, and trying to do something like that will lead to a path of suffering. Options I see include
Creating a separate assembly (and output Jar) for each version (see Maven Assembly Plugin)
Create a multi-project reactor with a separate output configuration for every project. Keep common code in one project that you link as dependency from the others. Possibly use the maven-shade-plugin to re-link the packages in your common project into the individual output projects
As you can see, both of these approaches are pretty hacky and require advanced Maven skills. It would be much easier to have parameterized builds where you pass in the output version. But that would make sense on a CI server like Jenkins.
I need to confirm what I suspect as I cannot find any documentation on it, so this would appear a silly question, and since I am a learner at eclipse PDE.
Initially,
I had a parent project pom of an eclipse plugin project with
<version>1.1.0-SNAPSHOT</version>
with two child projects, with both their poms referring to the parent pom as version 1.1.0-SNAPSHOT.
I was able to build the projects successfully and had a site which I use to install the plugin into eclipse.
Then, I wanted my personal temp version called 1.1.1-mine. So I modified the three poms to
1.1.1-mine
I also updated the META-INF/MANIFEST.MF and feature.xml from
0.13.0.qualifier
to
0.13.1.qualifier
However, the build encountered the following error.
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.15.0:validate-version (default-validate-version) on project org.sonatype.m2e.subclipse: OSGi version 1.1.1.qualifier in META-INF/MANIFEST.MF does not match Maven version 1.1.1-mine in pom.xml
Does qualifier have to be a maven version keyword? Because, the build proceeded without error after I changed mine to SNAPSHOT in the poms.
If not, what did I do wrong?
What can I do to allow me to have version 1.1.1-mine?
In a nutshell, OSGi .qualifier means the same thing as -SNAPSHOT.
Since OSGi doesn't allow for more than 3 numbers in a version (+ qualifier), creating a -mine version is a bit tricky.
According to the FAQ, you can tell Tycho a string that it should be use to replace qualifier with:
mvn -DforceContextQualifier=mine
Note that this disables all the goodness you get from SNAPSHOT versions (namely that you can deploy the bundle several times).
Is there a way to make maven build 1.5 and 1.6 bytecode jars simultaneously. I know I can use classifiers to name them, but this forces to me to build them separately. I would ultimately like to do the following:
mvn clean install
And in my target directory see something like:
fooSource.jar
foo-1.6.jar
foo-1.5.jar
Is there a way to make maven build 1.5 and 1.6 bytecode jars simultaneously?
No, you'll have to run two clean builds. I'd use profiles and a CI engine supporting build matrix for this (Hudson does).
You can try using sub-projects (modules) with different compiler configurations.
But except for installing the repository, this wouldn't be useful. Instead you can use maven profiles in order to generate different artifacts in different cases.