Please see https://github.com/eclipse-lsp4j/lsp4j/issues/738 for the LSP4J issue.
Jonah ~~~ Jonah Graham (he/him) Kichwa Coders www.kichwacoders.com On Thu, 1 Jun 2023 at 03:02, Ed Merks <ed.me...@gmail.com> wrote: > The staging repository content of > > https://download.eclipse.org/staging/2023-06/ > > has been promoted to the following repository for 2023-06 RC1: > > https://download.eclipse.org/releases/2023-06 /202306021000/ > > This is ready for consumption by EPP. > > It will become visible in the composite as scheduled Friday, June 2nd, > 2023: > > https://download.eclipse.org/releases/2023-06 > > _______________________________________________ > > STOP INCLUDING 3rd PARTY BUNDLES IN FEATURES > > This is the first time in a very long time that we've reduced the number > of duplicates: > > > https://download.eclipse.org/releases/2023-06/202306021000/buildInfo/archive/download.eclipse.org/releases/2023-06/202306021000/index.html > > The most common reason for duplicates (though not the only one) is > including 3rd party bundles in your features, e.g., here the platform > requires one specific version of gson while papyrus another: > > In this case, lsp4j is depending on an internal package not exported by > the direct-from-maven version of gson. I wonder if or why that's necessary? > > There is a proposal to stop including 3rd party bundles in features: > > https://github.com/eclipse/orbit/issues/8#issuecomment-1534255305 > > I plan to help the platform and other projects stop doing that: > > > https://github.com/eclipse-platform/eclipse.platform.releng/issues/230#issuecomment-1560452454 > > For the platform is relatively easy because they're at the bottom of the > food chain so they can just specify to include all transitive requirements > in their repository. For most of us though, we cannot and should not > replicate project content of other Eclipse projects, so we must take a > different approach. My suggestion here is to introduce an additional > "dependencies" feature that's included uncategorized in the category.xml > and to move all 3rd party bundle includes to that feature (and DO NOT > include that feature in any other feature that the user installs). > > You might think, "but I want to be sure that a specific tested version of > some 3rd party dependency is used". Dream on then because there is no > guarantee that OSGi will actually wire your bundles to any specific 3rd > party bundle version even if that version is available in the > installation. The wiring will depend only on the version ranges in your > actual bundles, not on the versions included by the features. > Regards, > Ed > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
