In the light of @Thomas Maeder said about the interop with LS, I think
we should prioritize the safety of the end user (a user applying a
plugin to his/her workspace) when combining different plugins over the
flexibility for the plugin authors.
At the same time, I find nothing wrong with the volumes approach.
So my current plan is to:
1) use mountSources=true|false to mount projects volume to /projects
2) allow the plugin to manually mount projects volume to '/projects'
Is not it overkill for plugin developer?
I guess as a plugin developer I would need to work with source code
and not care about the way it provided and managed?
3) issue some kind of warning when the plugin tries to mount projects
volume to a different path
4) Reject running the plugin if it defines both mountSource=true and a
custom mount of projects volume
How to best warn the plugin about the mounting problem is an open
question - maybe we should do it early and actually warn about it
already and the build time of the plugin but we should also do it at
runtime when deploying the plugin, but I'm not sure about the best way
of handing that warning to the user.
WDYT?
On 22. 01. 19 8:38, Serhii Leshchenko wrote:
> I think we can introduce boolean property `mountProjectSources` and do not
> deprecate the current approach with `projects` named volume.
> Then we would hide complexity for users who do not need configuring mount
> path and in the same time, a user is able to override mount path.
> @Mario Loriedo <mloriedo@xxxxxxxxxx> Do you think it is good enough or we
> need to make the source code path configurable in another way like
> introducing optional string property?
>
> On Mon, Jan 21, 2019 at 7:27 PM Mario <mario.loriedo@xxxxxxxxx> wrote:
>
>> Lukas we may be able to make the source code path configurable eventually.
>> But that looks tricky and has a few side effects (i.e. IDE and LS sync). So
>> I would rather split the problem in 2 distinct issues:
>> - hide complexity to users that don't want to bother where the source code
>> is located (the issue you are working on)
>> - make the source code path configurable (new issue)
>>
>> Anyway thanks for starting the discussion and I have voted for one of your
>> proposals.
>>
>> On Mon, Jan 21, 2019 at 3:19 PM Lukas Krejci <lkrejci@xxxxxxxxxx> wrote:
>>
>>> I'm reading that as that it is better to hardcode the root of the
>>> projects to some "well-known" path. That way we can ensure that the URIs
>>> will have a better chance at being the same.
>>>
>>> As one of the crowd who's lacking the technical expertise in the
>>> minutiae of the IDE<->plugin<->server interactions, I'm glad I asked :)
>>>
>>>
>>> On 21. 01. 19 13:48, tmader@xxxxxxxxxx wrote:
>>>> On Mon, 2019-01-21 at 13:43 +0200, Oleksandr Garagatyi wrote:
>>>>> I would consider other technical reasons before letting the crowd
>>>>> decide since the crowd might lack technical expertise in this area.
>>>>> Several months ago Yevhen Vydolob told me that one cannot just change
>>>>> the path if Language servers are used. The reason os that path of
>>>>> files that get changed is sent from Editor to a language server.
>>>>> Since they can be located in different containers changing an
>>>>> absolute path can break everything.
>>>>> I do NOT know whether the constraints have changed since then.
>>>>> @Yevhen Vydolob @Florent Benoit @Thomas Maeder please, share your
>>>>> expertise here.
>>>>
>>>> LSP uses URIs to identify resources. While not mandated by the
>>>> protocol, these will be file URI's and thus include the full file
>>>> system path. This means that the language server and the ide need to
>>>> see the files in the IDE workspace at the same location. It doesn't
>>>> have to be "/projects", but it has to be the same for the language
>>>> server and the IDE.
>>>>
>>>> does this help?
>>>>
>>>> /Thomas
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> che-dev mailing list
>>>> che-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/che-dev
>>>>
>>> _______________________________________________
>>> che-dev mailing list
>>> che-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/che-dev
>>>
>> _______________________________________________
>> che-dev mailing list
>> che-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/che-dev
>>
>
>
>
> _______________________________________________
> che-dev mailing list
> che-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/che-dev
>
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
