Is there a common way of finding out which version of a Maven artifact is compiled against which Java version?
It always seems to take way too long to
Work out that it is a jvm version issue
Find out which jvm version the current aritfact uses
Track back through the versions of the artifact to find one that works
If there is not a common mechanism, do some artifacts adopt a naming convention?
There is a standard way of naming, using the classifier attribute of an artifact.
Building same project in Maven with different artifactid (based on JDK used)
Related
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.
I want to use different selenium versions (3.141.59 and 4.1.0) for running my project in chrome and firefox browser and android,
Is it possible to use different version of selenium dependency in POM for different browsers in same JAVA project?, if so how it will code.
You can define, but only one will be picked at a time !
As per maven documentation
Dependency mediation - this determines what version of an artifact will be chosen when multiple versions are encountered as dependencies. Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins
Read more about it here
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Ideally I'll suggest to you to use a stable version of selenium compatible with both browsers !
In my maven project, I am looking for a way to create an artifact alias for an artifact that I have created. The reason is that a specific artifact used to be deployed under with a different artifactId and I want to keep supporting this old artifactId for the time being, even for new releases, without having to have a full duplicate module for this other artifact.
For example. Say I have the artifact foo-bar in version 1.0 of my project and I decided to rename this artifact to foo-baz in version 2.0, but I still want to support the foo-bar artifactId until the release of version 3.0, for backwards compatibility reasons.
So therefore I want to find a way to define foo-bar as an alias for foo-baz. Is this possible to do?
This is called a relocation but If I correctly remember you can't relocate an artifactId you can only relocate an groupId...Apart from that I would announce that change with the current 2.X releases and then simply change the artifactId for the first 3.X release. The decision to rename an artifact is a breaking change which in itself is a reason to make major version change..which you seemed to miss...
I want to find all the higher versions available for each dependency and download them all of them. I tried to get the version by this command
versions:display-dependency-updates
But it is only displaying the latest version. Instead how should I find all higher versions using a java.
First of all, updating all the dependencies of a project just for having the latest version isn't the most recommended option. You may encounter unintended consequences such as, for example, changing the Java version with which the projects were compiled so you can't deploy your application on your server. My recommendation is that you always keep control of the dependencies you use in your projects and define a specific value appropriate to your needs. But if the supplier of the dependencies is a trustworthy organization and maintains compatibility between its versions, you can use the maven dependency syntax to get the latest. Dependency Version Ranges
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).