Hello,
While we should make efforts to minimize duplications, and thanks to Ed to encourage that, it's also great to acknowledge that this is not a primary goal of SimRel and that we should praise the people who decided to make Eclipse Platform rely on OSGi so such duplications of non-singleton libraries is actually not a problem!
So let's just take a few seconds and think about how OSGi helps us continuously. (I've read negative comments about OSGi lately, and find those very unfair so I'm trying to make people realize what kinds of difficult problems it does resolve, and how easy can be the solutions it provides).
Back to this specific case...
> It looks like lsp4e uses quite tight version ranges for lsp4j. For
example the latest released version org.eclipse.lsp4e 0.15
requires-bundle org.eclipse.lsp4j;bundle-version="[0.19.0,0.20.0)".
Since lsp4j 0.20 is directly contributed to SimRel and lsp4e requires lsp4j 0.19 both versions apear in the SimRel-repo.
Indeed, LSP4E uses tight ranges for LSP4J because LSP4J API is changing in non-backward compatible-ways (this is necessary to support changes in Language Server Protocol).
And indeed, latest release of LSP4E (0.21) does use LSP4J 0.19 (not latest).
lsp4e was already updated to lsp4j 0.20 by Mickael five days ago:
So as soon as the next lsp4e release (I assume 0.22) is contributed to SimRel only one version of lsp4j should remain.
@Mickael can you tell/estimate when this will be?
LSP4E has received many big changes in the last weeks, including some strong API changes, for a much better result on many aspect. However, those refactorings are still ongoing and the current state is a mix of old and new without clear deprecation, it's improper tor release at the moment. so LSP4E won't be ready for release in 2022-03. So LSP4J 0.19 will have to stay.
I believe there are still 2 or 3 weeks of work at the current pace before we can release the new and better LSP4E.
The two different 2.10.1 versions of gson are probably due to the fact that lsp4j uses gson 2.10.1 from Maven-Central, while somebody else uses gson 2.10.1 from Orbit:
But what I don't understand is, why does Orbit even contain a recent version of gson? In m2e we use gson 2.10.1 from central and it looks like it already has proper OSGi metadata.
Therefore I don't really understand why the version from Orbit is even used and provided?
I agree that Orbit duplicating a bundle that exists in a usable state upstream can be the root of many other issues. As we have an example here that this has a cost to troubleshot, and that there was probably a cost in setting up the Orbit clone; I'm also curious about what is the expected added-value that makes this cost profitable enough to be perceived as an reasonable investment?
