Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [epp-dev] EPP 2023-03 M3
I think the problem is not OSGi or singeltons, but that lsp4e and lsp4j actually are closely related (whats not bad per se), so at the moment I think if there is a new release, both should (after upgrading) doing a release (some kind of micro-simrel ;-)) unless both projects agree that the API is stable enough to use proper version ranges and use-clauses and then it would also work to decouple the releases all together.
For that purpose, I have added the bnd-baseline check to m2e as an incubator (and until now it really works well!) that helps enforcing strict semantic-version rules [1].
Another important thing might be to decorate lsp4j API with @ProviderType and @ConsumerType (recently added to Tycho + PDE as well!) to help such tools to make good decisions. Also automated Bundle Manifest export/import might help here (I'm currently working on bring better support for PDE in that area).
So I can only encourage people using these techniques to build better bundles to reduce such hassle in the future and of course feel free to ask if any help is needed to apply such techniques to projects.
[1] https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#new-tycho-baseline-plugin 

Am 27.02.23 um 09:30 schrieb Mickael Istria:

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-bundleorg.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).
On Mon, Feb 27, 2023 at 12:57 AM Hannes Wellmann <hanneswellmann@xxxxxx <mailto:hanneswellmann@xxxxxx>> wrote: 

    lsp4e was already updated to lsp4j 0.20 by Mickael five days ago:
    https://github.com/eclipse/lsp4e/commit/ad0c6a19481f5c729b45a3784fec94201d217085 <https://github.com/eclipse/lsp4e/commit/ad0c6a19481f5c729b45a3784fec94201d217085>
      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:
    https://download.eclipse.org/tools/orbit/downloads/drops/I20230215045902/ <https://download.eclipse.org/tools/orbit/downloads/drops/I20230215045902/>
      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?

Back to the top