What is an OSGI version qualifier - java

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).

Related

Maven Eclipse plugin bug? failing to auto-add in-workspace dependency JAR to Run Configuration module-path

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.

maven version tag [1.0,) does not work

I have the following dependency defined in my pom.xml
<dependency>
<groupId>runtime_shared</groupId>
<artifactId>org.boofcv</artifactId>
<version>[1.0,)</version>
</dependency>
with which I wanted to say "Take all the jars starting from version 1.0". I guess this is the correct way.
I have two versions in my local repository (.m2/repository) and I need both of these jars to have a successful compilation. However, I get an error saying that some packages do not exist. I checked the debug output and saw that maven only considers one of the jars (the last version) during the compilation, disregards the other one. And when I looked at the error message closely, I noticed that the packages it is talking about, are in the jar which is disregarded.
[DEBUG] /home/user/.m2/repository/runtime_shared/org.boofcv/1.0.2/org.boofcv-1.0.2.jar
Does anyone know why isn't version tag working?
You are referring to a syntax unique to the maven enforcer plugin.
Such syntax like [1.0,) is not valid for normal use of maven projects.
As per Jens' comment, you should specify a concrete version.
Here is the plugin documentation

New maven dependency version pulling pom, not jar into private nexus repo?

I'm upgrading some dependency versions I have in a java/maven/spring application, which is using our nexus repo as the central repository mirroring maven central.
I tried upgrading hibernate to it's newest version of 3.5.4-Final as listed:
Hibernate newest release stable version
And when I run maven install, I see in my nexus server that there is now 3.5.4-Final listed, but inside its directory there is only a pom.xml file for the project and none of it's associated JAR's.
When I inspect the POM, I can see it's packaging is listed as POM and not JAR.
Why is this, and how can I make maven take the jar packaged version of the library rather than just the POM?
EDIT - mvn install error message posted:
[ERROR] Failed to execute goal on project app: Could not resolve dependencies for project com.app:app:war:16.2.1-SNAPSHOT: Failure to find org.hibernate:hibernate:jar:3.5.4-Final in http://ssp-nexus1.mynexus-server.com:8081/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of company.nexus.mirror has elapsed or updates are forced -> [Help 1]
As mentioned in the link you provided
Aggregator of the Hibernate Core modules.
So, the artifact you linked is effectively a pom which aggregates (as a multimodule) other Hibernate artefacts.
Instead, the hibernate-core artifact, as an example, can be found here, as a standard maven dependency (that is, a jar).
By default dependencies have type jar, so if you add the maven coordinates (GAV) for a dependency that is instead of type pom, maven will then look up for it as a jar. So that's why you are getting the error mentioned in your edit.
You should remove its dependency from your pom and only add the hibernate dependency you effectively need. As a rule of thumb, add the dependency you explicitly use in your code (as import statements, for instance) or your configuration files, and let then maven take care of the required transitive dependencies, given that they will be available on your company repository, obviously.
Update
Following your latest comments and feedback, here is a further explanation about why just changing the version of the existing Hibernate dependency you got to this issue:
The new 3.5.4-Final and the previous 3.2.7.ga version share the same groupId and artifactId on the Maven repository
However, the former has type pom (it's a pom file), while the latter has type jar (the default one)
So, the previously existing version was working fine and changing the version of the dependency you switched it from jar to pom, breaking the maven resolution (which was looking for a jar for a version which instead was a pom)
This mainly happened because you switched from a ga to a FINAL version. For a further explanation about the difference between these versions, you can check this SO question and this one
As a side note, I find a bit inconsistent that changing a version number also changes the dependency type, it might a point of debate, but if I were the Hibernate team, I would handle this version management differently.

Maven dependency version mismatch issue - resolving outdated version of dependency from repo

When I try to build my Maven project in Eclipse, I'm getting this build failure message:
[INFO] Checking for transitive/resolved version mismatches.
[INFO] com.company.etc:artifact-name:
[INFO] required: 1.5
[INFO] resolved: 1.3
My POM file is requesting version 1.5 of this artifact, so that part is correct. But on the repository listed, versions 1.3, 1.4, and 1.5 are all available, with the correct maven-metadata.xml file in the root directory as well. Simply changing my POM file requirements to the older version is not an option, since I need the features in the newest version of the artifact.
I'm really stumped here. Is there anything I'm overlooking that might cause Maven to resolve a lower version number than what is actually available on the repo server?
There are two possible solutions that I found for this issue:
The first one is to specify an exact version requirement, or "hard requirement" for a specific version of a dependency, as shown below:
<version>[1.5]</version>
instead of:
<version>1.5</version>
The second one is to use the mvn dependency:tree Maven command to see exactly what dependencies are being pulled in, and in what hierarchy. In my case, this solved my problem when I noticed that one dependency was actually pulling in an older version of another dependency, as a sub-dependency. Despite the fact that the sub-dependency was specified on its own elsewhere in the POM, Maven used the older version that was pulled in as a sub-dependency. Sounds confusing I know, but either way, mvn dependency:tree should show if a dependency is being pulled in unknowingly, or at an unspecified version.

Cross-Project Versioning for Eclipse Plugins

i have multiple Elipse plugin projects that depend on each other. Several questions concerning that:
1) If i change the version number of one plugin, is it somehow possible to automatically update the plugin.xml files of the dependent plugins to reflect the version number change?
2) The same for Maven pom's: can i somehow automatically update the pom's when i change version numbers?
3) If i want to keep plugin.xml and pom.xml version numbers consistent, is there an automatic way to do so?
4) and last: If i have multiple projects that should have the same version numbers, can i somehow sync the version numbers?
Using the Maven Release Plugin - and especially the update-versions goal - may solve at least some of the issues you have addressed.
From the documentation at http://maven.apache.org/:
In some situations you may want an easy way to update the version numbers in each POM of a multi-module project. The update-versions goal is designed to accomplish this.
To update the version numbers in your POMs, run:
mvn release:update-versions
You will be prompted for the version number for each module of the project. If you prefer that each module version be the same as the parent POM, you can use the option autoVersionSubmodules.
mvn release:update-versions -DautoVersionSubmodules=true
In this case you will only be prompted for the desired version number once.
As pointed out by khmarbaise, there is Tycho, which is a maven plugin that works as bridge between maven and eclipse plugins.
Those two links provide the information needed to achieve what i asked in my question:
https://docs.sonatype.org/display/M2ECLIPSE/Staging+and+releasing+new+M2Eclipse+release
http://software.2206966.n2.nabble.com/Incrementing-updating-release-version-of-plugins-while-generating-p2-site-td5929658.html
It seems like you need to use the command
mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version>
which should set all versions of the parent pom, the modules, and the plugin.xml 's to the given version.lik

Categories