Failure to simultaneously resolve two consumers using each of v2.10.1 and v2.11.0 together in Eclipse IDE #2725
Comments
scottkurz
changed the title
scottkurz
changed the title
|
(Disclaimer: I am not very familiar with OSGi) Maybe related to #1001 Gson does not explicitly define I guess we could remove these self imports by writing something like: But I am not sure if omitting the import could have any negative side effect. Or if alternatively it is possible to specify the version for the import, and if that has any negative side effect. Maybe we should raise this issue at https://github.com/bndtools/bnd? |
This was the suggestion in the comment from @rgrunber in: eclipse-jdtls/eclipse.jdt.ls#3236 (comment) noting another packaging of this bundle: https://git.eclipse.org/r/plugins/gitiles/orbit/orbit-recipes/+/refs/heads/master/google/com.google.gson_2.10.1/osgi.bnd I'm not too familiar with either the history or the bnd syntax here, nor the ramifications really, just making the connection there in noting that. |
|
The self import is fine to keep as long as the range is tight enough so as to never include a package from another version of that library. The current self-import is unbounded. You could probably make the range even tighter with |
|
I have created bndtools/bnd#6220 to clarify if bnd-maven-plugin should generate these version ranges on its own by default (and to clarify what they think the correct behavior should be). But while trying to change this locally for Gson I noticed some rather strange behavior of the plugin, bndtools/bnd#6221. It seems the |
|
Some older discussion on the situation : https://bugs.eclipse.org/bugs/show_bug.cgi?id=183595 . |
|
In bndtools/bnd#6220 (comment) it was proposed to add e.g. in the bnd section of gson's pom.xml This would result in a Maybe it can even be done for all the gson packages currently exported. I'll try to create a PR for this. |
based on google#2725 and bndtools/bnd#6220 (comment) append -noimport:=true to all exports which we do not want to re-import This avoids issues in OSGi environments where multiple versions of gson are deployed and com.google.gson.annotations causes wiring conflicts between these different versions
based on #2725 and bndtools/bnd#6220 (comment) append -noimport:=true to all exports which we do not want to re-import This avoids issues in OSGi environments where multiple versions of gson are deployed and com.google.gson.annotations causes wiring conflicts between these different versions
Gson version
v2.10.1 and v2.11.0, together in an OSGi runtime
Java / Android version
Java 21
Used tools
Eclipse IDE 2024-06 release, "Enterprise Java" package
Description
As described in eclipse-jdtls/eclipse.jdt.ls#3236 (comment)
I'm trying to load two versions of the same bundle, one which uses gson v2.10.1 and the other using gson v2.11.0.
In more detail, first, there is lsp4j v0.22.0 with
Import-Package: com.google.gson;version="[2.9.1,2.11)",com.google.gson.a nnotations;version="[2.9.1,2.11)",(shown here as part of a bigger excerpt of the bundle MF):
Next, there is lsp4j v0.23.1 with
Import-Package: com.google.gson;version="[2.9.1,3.0)",com.google.gson.an notations;version="[2.9.1,3.0)"(Bigger bundle MF excerpt here:)
Though I have gson v2.10.1 and 2.11.0 installed I can't resolve both versions of lsp4j. The OSGi console in Eclipse shows:
As noted in this issue response, the problem seems likely related to the way in which the
com.google.gsonimports com.google.gson.annotations without any qualifications on the version.Reproduction steps
Besides the original recreate, a simpler method would be:
Help -> Install New Software then click Add button.
For Location field add
https://download.eclipse.org/lsp4j/updates/releases/0.22.0then click Add.Window->Show View->Console, select "Host OSGi Console" from drop-down
lb org.eclipse.lsp4jYou'll see something like:
diag 1013(or whatever bundle # you see in the prev. cmd):You'll see something like:
The text was updated successfully, but these errors were encountered: