Well, the complexity lies more in the fact that
mountPath: "/projects"
name: projects
requires some implicit knowledge, not only the names of the attributes
but also their values, while
mountSources=true
is easier in that regard.
In a case of default path can not it be provided by entry w/o (or with empty) mountPath instead?
Is not it more consistent option?
Also the latter allows us to sidestep a potential problem with plugin
interoperability that @Thomas Maeder highlighted - the need for a single
URI representing the same file across different plugins (which could be
violated if each plugin mounted the sources on a different path).
I would say it is two different things.
LS should be able to know where project tree (folder) located
On 22. 01. 19 9:24, Gennady Azarenkov wrote:
> On Tue, Jan 22, 2019 at 9:39 AM Serhii Leshchenko <sleshche@xxxxxxxxxx>
> 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.
>>
>
> By "hiding complexity" meaning replacing:
>
> mountPath: "/projects"
> name: projects
>
>
> with
> mountProjectSources=true
>
> ?
>
> @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
>>>
>>
>>
>> --
>>
>> Serhii Leshchenko
>>
>> SENIOR SOFTWARE ENGINEER
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>> <https://red.ht/sig>
>> _______________________________________________
>> 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
