Introduce an lsp4e feature containing all bundles

[travkin79]

Is there a reason why lsp4e doesn't have a feature project that includes all plug-ins? I suggest to introduce such a feature project.

The main advantage would be being able to install or update all lsp4e plug-ins that belong together. Otherwise, if non-lsp4e plug-ins do not have dependencies to each of the lsp4e plug-ins, e.g. the org.eclipse.lsp4e.debug plug-in, we might miss some version updates.

[mickaelistria]

Is there a reason why lsp4e doesn't have a feature project that includes all plug-ins?

So far, there has been no need for such feature.

The main advantage would be being able to install or update all lsp4e plug-ins that belong together.

p2 and OSGi dependency management does it very well without features, provided the right versions are set in MANIFEST.MF. "Belong together" is not a 1-1 mapping, it's a N-N one, and this N-N mapping gives great opportunities (partial updates, esoteric but still working combinations...) that features tend to break.

LSP4E is not really meant at being a end-user feature, it's more an integration level project. So it doesn't seem so interesting to make a feature for it, particularly as features tend to block to some older versions or to make upgrades more complex (features are extra constraints).

I think what you have in mind is more that p2 in general doesn't provide "deep" updates easily. That's a different problem that would better be fixed in p2 than starting to build workarounds for it in all Eclipse projects.

[iloveeclipse]

The use case is basically following:

• we have custom tooling on top of CDT for our internal IDE setup
• that tooling is based (indirectly) on CDT lsp4e support
• CDT requires minimum lsp4e which is very old
• lsp4e is updated to fix issues we see
• waiting for next CDT release that would be with updated dependency is wasting time
• updating our tooling to add an extra minimal lsp4e requirement is possible but technically wrong (as we don't directly refer to it, just using CDT)
• so all what we would need as an updated lsp4e feature, so we could update the stack below without touching CDT / our tooling.

What we do is to "force" oomph to install minimum lsp4e bundle version, but that is far from being convenient, compared to the updated lsp4e feature that would simply be placed to update site & Eclipse would automatically update it once it is there.

[laeubi]

lsp4j already seem to offer a repository so one can simply install an update from there, once the updatesite is added to the product and lsp4j is installed Eclipse should offer the usual update mechanism.

[iloveeclipse]

This doesn't work, that's the reason of the requesting a feature.

[laeubi]

This doesn't work, that's the reason of the requesting a feature.

This is not a suitable report one can act on, e.g please specify what dos not work, how it maybe can be reproduced and what is the expected outcome.

[iloveeclipse]

There is no update offered, what else should be reported?

[laeubi]

Then a feature won't make a difference, what else should be said?

I offered you clear instructions on how you can make it work but no one knwo what you have tried or what problems you are seeing beside "it do not work", so:

• Did you added the lsp4e update site in your eclipse?
• Was you able to install lsp4e from that site?
• Did "check for updates" for later release of lsp4e gives you an update, can it be installed?
• ...

[martinlippert]

Just one more thought from my side here. Not really arguing in favor or against a feature definition, but I would keep this in mind when introducing a feature (not totally lsp4e specific though):

Features usually contain fixed versions of the plugins included, which can cause "interesting" issues when updating components in the install. As long as the feature is around (and not updated itself), no other component might be able to install a newer version of lsp4e bundles. Might be totally okay for your use case though, but I am not sure that I would include a feature requirement to this new lsp4e feature in CDT itself.

[laeubi]

@martinlippert while I agree here that features can cause strange results, if you see issue again heavily depends on how they are used, so it is not true that one can't install a new feature or another plugin in general but depends on the context.