-
Notifications
You must be signed in to change notification settings - Fork 111
Conversation
[crw-ci-test --rebuild] |
export class PluginResourceResolver implements ResourceResolver { | ||
resolve(uri: URI): MaybePromise<Resource> { | ||
if (uri.scheme !== PluginUri.SCHEME) { | ||
throw new Error('Not a plugin resource'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Provides the uri that is invalid ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. Note that throwing an exception is just the way for the plugin resolver to indicate it cannot handle this scheme. The error is swallowed silently.
* front end. | ||
*/ | ||
export namespace PluginUri { | ||
export const SCHEME = 'pluginresource'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's specific to che, probably add che into the SCHEME (in case upstream provides pluginresource as well) to avoid any mismatch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not really specific to che: the plugin resources at /hostedPlugin/... are also available upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's tied to che because this protocol is not available upstream
result.push({ | ||
language: contribution.language, | ||
source: pck.displayName || pck.name, | ||
uri: PluginUri.createUri(getPluginId(pck), relativePath), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should just simply make a SnippetContributionProviderURI or SnippetContributionProvider singleton upstream and then just overrides how we create URI downstream
Here there are too many overrides
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean, there are too many overrides? It's a single method. If we extract the various contribution providers upstream, we would logically have to to it for all kinds of contributions. That may or may not be desirable, but one of the reasons we're doing this downstream is that the work was deemed urgent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean here that there are too many classes being extended (and we may miss some of them)
while we're only interested on delegating the contribution uri.
That may or may not be desirable, but one of the reasons we're doing this downstream is that the work was deemed urgent.
eclipse-che/che#16502 is opened since march
I think that adding a new simple method in upstream theia to handle the contribution can be accepted in a couple of days as it's a very minor change.
Also we could just delegate the creation of URI for a plug-in (not tied to snippets) and use for upstream theia File protocol and for che: a custom provider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand it, this issue is not reproducible in upstream theia. In the interest of saving time, I suggest we keep the fix downstream: not only because the benefit for theia is low, but also because the holidays are coming and getting the PR merged on time is not guaranteed. We can always iterate later if the need for such methods in theia arises.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it would be a problem to have something merge upstream if it's only an helper to get an URI for a plugin resource. Upstream theia having implementation with File and downstream with something else.
Discussing it is taking more time than having proposed a simple tiny PR url upstream.
Also I see two different ways being implemented for getting resources for a plug-in this one and #946 which is kind of colliding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked explicitly on a Theia dev call whether separation of plugin host and back end on different machines was something that should be supported in Theia and the answer was no. Hence the downstream effort instead of pursuing eclipse-theia/theia#8468
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And again, we can push for this refactoring upstream any time later, but we already have all the necessary parts to fix the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's different. It's not to have a plug-in-resource: protocol upstream, just to have something than convert a plug-in path to an URI by using File and that can be replaced in Che (with protocols, etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @benoitf. Here using inheritance and overrides could be quite hard to maintain in the future. It is overriding methods and copying some parts of upstream code. So if, somehow, in upstream, someone changes that line https://github.com/eclipse-theia/theia/blob/bd25d737742a0974b911da5d3a5c978d950fc64e/packages/monaco/src/browser/monaco-snippet-suggest-provider.ts#L146, it would not be reflected downstream and could cause bugs that are hard to track.
* The path is resolve relative to the directory designated by the | ||
* plugins package path. | ||
*/ | ||
export class PluginResource implements Resource { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be a ChePluginResource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not Che specific, even if it lives inside che-theia: same reasoning as above. I'm open to proposing a PR upstream with the plugin resource stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's becoming an upstream yes it'll be a pluginResource else it'll be a Che plugin resource.
Proposing it upstream will be better if you want to stick to 'pluginResource'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I think it's only useful upstream if this protocol is used somewhere
[crw-ci-test] |
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
[crw-ci-test --rebuild] |
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
[crw-ci-test --rebuild] |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
[crw-ci-test --rebuild] |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
I've tried using the sidecar file system to load snippet files, but that does not work because monaco tries to fetch the snippet files before the sidecar files system is registered. |
@tsmaeder we can't register the filesystem earlier ? |
@benoitf not easily: the file system is initialized when the plugin manager for a particular front-end is initialized. However, the initialization of connections to plugin hosts is done in parallel to opening the editor, it seems. I believe we would have to rework the lifecycle of plugin host connections. T.b.h, I think it would be beneficial to the project, but might introduce bugs and will delay startup. |
@benoitf could we move forward with this PR? It works and your suggestion of introducing a |
as compromise, I'm fine to keep the logic of custom URI on Che-Theia, but not having to override multiple scanners / copy almost all content of upstream readSnippets |
|
@tsmaeder to keep ChePluginResource and CheSnippetSuggestProvider, but remove the need of CheTheiaPluginScanner, CheVsCodePluginScanner by implementing upstream the delegation of readSnippet URI (SnippetContributionProviderURI) |
I'm ok to have it merge if during the upcoming sprint, SnippetContributionProviderURI is coming, and icing on the cake, we can remove ChepluginUri/chepluginresource and use an eager registration of filesystem provider
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
dd554e0
to
74c25db
Compare
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
If we want this in Che 7.26, we'll need to backport this PR and also fork theia at this commit and cherry pick the upstream fix onto our fork. |
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
398ccfa
to
0f12eb8
Compare
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
0f12eb8
to
ac402f3
Compare
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
@azatsarynnyy @ericwill have another look, if you please. PR is considerably changed, so you should re-review |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
extensions/eclipse-che-theia-plugin-remote/src/node/plugin-remote-backend-module.ts
Outdated
Show resolved
Hide resolved
return; | ||
} | ||
} | ||
|
||
requestPluginResourceStat(pluginId: string, resourcePath: string): Promise<Stat> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for readability maybe it would be easier to flag it as async method (and use await instead of chaining promises)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used to like the async/await syntax, but t.b.h these days I find it makes following the control flow rather confusing, in particular when debugging. I tend to only use async/await where it really improves readability. Here it does not, IMO:
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
as it's a bugfix, would be nice to have unit tests
all modules having now jest setup. |
@benoitf since this is a bug that rises from the integration of multiple components (containers, even), I don't see an easy way to write a unit test that would be meaningful. |
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
Signed-off-by: Thomas Mäder <tmader@redhat.com>
a314810
to
0f3faf1
Compare
Codecov Report
@@ Coverage Diff @@
## master #948 +/- ##
==========================================
- Coverage 21.07% 20.78% -0.29%
==========================================
Files 298 302 +4
Lines 11090 11244 +154
Branches 1680 1706 +26
==========================================
Hits 2337 2337
- Misses 8603 8756 +153
- Partials 150 151 +1
Continue to review full report at Codecov.
|
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Single User on K8S (minikube v1.1.1)
|
Signed-off-by: Thomas Mäder tmader@redhat.com
What does this PR do?
Load snippet resources via the plugin resource loading mechanism instead of file uris (like the are in Theia)
What issues does this PR fix or reference?
eclipse-che/che#16502
How to test this PR?
Use the Che-Theia image built for the happy-path test in any workspace including the Java plugin and try using snippets in any Java file.
PR Checklist
As the author of this Pull Request I made sure that:
What issues does this PR fix or reference
andHow to test this PR
completedReviewers
Reviewers, please comment how you tested the PR when approving it.
Happy Path Channel
HAPPY_PATH_CHANNEL=next