[#242] make API of org.eclipse.cdt.lsp.clangd package public

[ghentschke]

fixes #242

[iloveeclipse]

Any reason why this PR hangs for 3 weeks? Is there a chance to be merged soon?

[ghentschke]

Any reason why this PR hangs for 3 weeks? Is there a chance to be merged soon?

Yes. I would like to refactor the API of the cdt-lsp feature as described here.

[ruspl-afed]

Any reason why this PR hangs for 3 weeks? Is there a chance to be merged soon?

If you have any specific requests for API, it is good time to formulate them @iloveeclipse

[iloveeclipse]

I was askimg because we needed something that was supposed to be aded as API with this PR, but I have no idea what exactly was needed. @travkin79 should know.

[ghentschke]

My Plan is to refactor the API of the org.eclipse.cdt.lsp bundle first. See #277. Then we should refactor the org.eclipse.cdt.lsp.clangd bundle API and lifting the bundle version to 2.0.0

[travkin79]

If you have any specific requests for API, it is good time to formulate them

Our requirements come from #227. The PR #229 offers the opportunity to adapt the org.eclipse.cdt.lsp.clangd.ClangdConfigurationFileManager by overriding methods like enableSetCompilationDatabasePath(IProject). Doing so requires to implement a sub-class of ClangdConfigurationFileManager and registering it as a higher priority OSGi service for the service type org.eclipse.cdt.lsp.clangd.ClangdCProjectDescriptionListener (we use that type in a @Component annotation). In our custom ClangdConfigurationFileManager sub-class we get discouraged access warnings for these two types, since the API is not public, yet.

Another idea was being able to provide a custom ICLanguageServerProvider. We don't use that at the moment, but I tried to implement a custom ICLanguageServerProvider and needed access to the following types that are not part of the public API either: org.eclipse.cdt.lsp.clangd.ClangdConfiguration, org.eclipse.cdt.lsp.clangd.ClangdFallbackFlags. We either need these types in the public API or a class that we could subclass, for example, in order to override the method org.eclipse.cdt.lsp.internal.clangd.ClangdLanguageServerProvider#isEnabledFor(IProject). I would prefer the latter to avoid redundant implementation of getInitializationOptions(URI) and getCommands(URI).

[ghentschke]

If you have any specific requests for API, it is good time to formulate them

Our requirements come from #227. The PR #229 offers the opportunity to adapt the org.eclipse.cdt.lsp.clangd.ClangdConfigurationFileManager by overriding methods like enableSetCompilationDatabasePath(IProject). Doing so requires to implement a sub-class of ClangdConfigurationFileManager and registering it as a higher priority OSGi service for the service type org.eclipse.cdt.lsp.clangd.ClangdCProjectDescriptionListener (we use that type in a @Component annotation). In our custom ClangdConfigurationFileManager sub-class we get discouraged access warnings for these two types, since the API is not public, yet.

These files are with the PR #285 and #286 part of the public clangd API

Another idea was being able to provide a custom ICLanguageServerProvider. We don't use that at the moment, but I tried to implement a custom ICLanguageServerProvider and needed access to the following types that are not part of the public API either: org.eclipse.cdt.lsp.clangd.ClangdConfiguration, org.eclipse.cdt.lsp.clangd.ClangdFallbackFlags. We either need these types in the public API or a class that we could subclass, for example, in order to override the method org.eclipse.cdt.lsp.internal.clangd.ClangdLanguageServerProvider#isEnabledFor(IProject).

It should not be necessary for vendors to implement the ICLanguageServerProvider. To provide a custom enable the org.eclipse.cdt.lsp.editor.LanguageServerEnable interface has to be implemented as OSGi service with a service-ranking > 0.
E.g.:

@Component(property = {"service.ranking:Integer=1"})
public class ClangdLanguageServerEnable implements LanguageServerEnable {
        @Override
	public boolean isEnabledFor(IProject project) {
             // your custom enable
         }
}

[ruspl-afed]

@ghentschke is it still relevant?

[ghentschke]

@ghentschke is it still relevant?

No, became outdated.