| Re: [che-dev] Simplify mounting of project sources to plugins |
I am a bit late to the thread but why is the source code path a plugin level concern?
I can see this being a workspace (IDE) level setting but at the plugin level changing the
path for each plugin does not sound like something that will work. Most of the plugins
and tools that Che uses comes from desktop. These tools are used to working with
single filesystem hierarchies and with concepts like workspaces, I do not think they
will be ready to handle own file system hierarchy and a way to map this to IDE’s hierarchy.
Unless we are assuming that plugins will work on their own and never communicate with each other
or the IDE this setting is an invitation to break things.
Thanks,
Gorkem
On 22 Jan 2019, at 11:19, Oleksandr Garagatyi wrote:
Yes, Lukas, you are completely right. We can’t clone Che-plugin-broker into /projects since traditional go tooling would not work--вт, 22 янв. 2019 г. в 18:01, Lukas Krejci <lkrejci@xxxxxxxxxx>:
On 22. 01. 19 16:43, tmader@xxxxxxxxxx wrote:
> On Tue, 2019-01-22 at 17:32 +0200, Oleksandr Garagatyi wrote:
>> @Thomas Maeder
>> In Go world projects are located by the GOPATH. Usually, GOPATH env
>> var is exported in bash profile or so. E.g. export
>> GOPATH=/home/user/goAfter that Go compiler and utils follow next
>> structural location of files:
>> $GOPATH/src <- projects AND dependencies (though dependencies not
>> always go here)
>> $GOPATH/bin <- compiled and packaged Go apps (usually added to PATH
>> to launch tools from it, often used for go based linters and other Go
>> related tools)
>> $GOPATH/src contains folders that represent Go packages and usually
>> include source hosting like github.com or golang.org.
>> For example, when I'm working on Che broker repo my path is
>> $GOPATH/src/github.com/eclipse/che-plugin-broker or
>> /home/gaal/workspace/go/src/github.com/eclipse/che-plugin-broker on
>> my system in particular.
>> All the Go tools like linters, compiler, and others expect GOPATH to
>> be populated in the system and structure to be respected.
>>
>> Hope it helps. If not, please, let me know.
> Thanks for the explanation. Howerver, I don't think it's a problem for
> the tooling, because the tooling will be installed in the plugin
> sidecar, where we control the value of $GOPATH (as well as in the Theia
> container). Why should GOPATH not be /projects?
>
You need to checkout your code into a particular subdirectory of GOPATH
that corresponds to the "structure convention" of Go, if I am not
mistaken (and please correct me if I'm wrong, Alex, I'm a Go noob).
E.g. because che-plugin-broker is hosted on github, it *needs* to be
checked out precisely to
$GOPATH/src/github.com/eclipse/che-plugin-broker
is that compatible we how we checkout stuff into /projects?
> /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
Oleksandr Garagatyi
_______________________________________________
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