Using Quickfixes and a LanguageServer [message #1851462] |
Wed, 06 April 2022 09:53  |
Eclipse User |
|
|
|
Hi,
I am trying to implement quickfixes for a Language Server based on Xtext. I would like to use the API developed in https://github.com/eclipse/xtext-core/pull/1597 but the package org.eclipse.xtext.ide.editor.quickfix is not exported in the MANIFEST.MF, so when I refer to IQuickFixProvider or DiagnosticResolutionAcceptor , tycho produces this errors when compiling
[ERROR] import org.eclipse.xtext.ide.editor.quickfix.QuickFix;
[ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ERROR] Access restriction: The type 'QuickFix' is not API (restriction on classpath entry '/data/jenkins-slave/workspace/asmd-cf-gerrit-verify-pipeline@2/.repository/p2/osgi/bundle/org.eclipse.xtext.ide/2.26.0.v20220228-0751/org.eclipse.xtext.ide-2.26.0.v20220228-0751.jar')
[ERROR] import org.eclipse.xtext.ide.editor.quickfix.IQuickFixProvider;
[ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ERROR] Access restriction: The type 'IQuickFixProvider' is not API (restriction on classpath entry '/data/jenkins-slave/workspace/asmd-cf-gerrit-verify-pipeline@2/.repository/p2/osgi/bundle/org.eclipse.xtext.ide/2.26.0.v20220228-0751/org.eclipse.xtext.ide-2.26.0.v20220228-0751.jar')
and I do not know how to suppress the restriction, using @SuppressWarnings("restriction") works in eclipse IDE but not on the maven build with type, and the same for the following part in the .classpath file
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins">
<accessrules>
<accessrule kind="accessible" pattern="org/eclipse/xtext/ide/editor/quickfix/**"/>
</accessrules>
</classpathentry>
So, can this API be used? If so, how can I circunvent the error in tycho?
Kind Regards
|
|
|
|
Re: Using Quickfixes and a LanguageServer [message #1851471 is a reply to message #1851464] |
Wed, 06 April 2022 11:06   |
Eclipse User |
|
|
|
could we get a 2.26.1 release, that is a minor release based on 2.26.0, with that fix? That is very unlikely to break anything. If needed I can help with the maintenance release.
Waiting for a major release, probably several months is a not viable for us, and using snapshots for productive code is also not a good solution.
|
|
|
|
Re: Using Quickfixes and a LanguageServer [message #1851475 is a reply to message #1851472] |
Wed, 06 April 2022 11:52   |
Eclipse User |
|
|
|
can you also ask
in
tycho discussions on github if they can make use of
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins">
<accessrules>
<accessrule kind="accessible" pattern="org/eclipse/xtext/ide/editor/quickfix/**"/>
</accessrules>
</classpathentry>
|
|
|
Re: Using Quickfixes and a LanguageServer [message #1851476 is a reply to message #1851472] |
Wed, 06 April 2022 11:53   |
Eclipse User |
|
|
|
I am not sure I understand your question.
For development (that is, when the developer is working), we just use the JDT compiler , there I can access the package org.eclipse.xtext.ide.editor.quickfix and suppress the warning.
But our verify jobs build the code in the same way as our release jobs, and they is use Maven + Tycho. There I have the problem that the verify jobs are failing.
Are you suggesting we should use something else than Maven + Tycho for our jobs? I have no idea what we would need to do so, but I expect that would be a lot of effort, wouldn't it? Maybe you know something I do not know.
Thansk
|
|
|
|
Re: Using Quickfixes and a LanguageServer [message #1851483 is a reply to message #1851477] |
Wed, 06 April 2022 12:35   |
Eclipse User |
|
|
|
we support eclipse-xtext and eclipse-lsp for a transition period, so we need osgi at least for one product build. We could think about having special build for eclipse-lsp only, but it would be a lot of work to add all dependencies to the pom.xml and it would involve a lot of time waiting for builds to finish, etc. There is no joy in that :(
I think for us a hotfix is the best option by far, and it might solve the problem for other people, which increases the chances that Xtext gets feedback before on this particular API.
If that is not possible I think I would need to explore other possibilities which do not involved stop usage of Tycho, even though I am not sure what would be the preferred option. I am afraid to write publicly the options because they are all very ugly ;)
Regards
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04034 seconds