| Re: [che-dev] Plugins API |
Tyler Jewell | CEO | tyler@codenvy.com | 978.884.5355 |
taking advantage in conversation, can you provide the docs about project (API, etc.) ? I want to contribute with it, If i could.2016-02-02 14:04 GMT-04:00 Gennady Azarenkov <gazarenkov@xxxxxxxxxxx>:OK, I see your pointSo, about #1, well what I said is that there are no abstraction for code-assisting things but you probably (if you interested to of course) could try to make your Erlang extension for Che without this abstraction. It would be interesting exercise for us and BTW it would give us better idea about abstraction for the code-assisting things. So could you please give us some idea about of what you have in your Eclipse plugin in terms of Eclipse library etc dependencies or probably you can share your code or part of it. Just to have an idea how you use Eclipse framework. Maybe we could help with porting it to Che and this knowledge would be helpful for us as well.As for #3 - I would not say we have clear policy about this. Of course, any implementation of REST service can be used on backend the question for us is deploying other than Java web services in the agent - which is rather conceptual than technical problem. But can think about this as well as soon as have something to start prototyping.cheers,GennadyOn Tue, Feb 2, 2016 at 5:40 PM, Vlad Dumitrescu <vladdu55@xxxxxxxxx> wrote:Hello Gennady,Well, I would say that I have several goals, and they fall under categories 1 and 3.I have existing code (both Java and Erlang) and I'd like to reuse as much as possible in order to make it work with Che. As a first step, I could live with having the Erlang machinery hidden behind Java APIs (like it is in the existing code) and wrap that Java so that Che can work with it, but in the long term it would be cool to expose the services directly from Erlang. Then even the regular Eclipse code could use those services.The important part of your answer is at this moment "so far we do not have generic abstractions for it so really java specific things", so I won't lose time trying to find those abstractions. Do you have some plans/ideas about how these abstractions might look like? I tried to define these last year, but I have little experience in this area and the result was too horrible to look at. Where in your time plan would this find a place - 3 months, 6 months, a year?best regards,VladOn Tue, Feb 2, 2016 at 3:35 PM, Gennady Azarenkov <gazarenkov@xxxxxxxxxxx> wrote:Hi Vlad,Interesting context and good questions.That's what we do for projects management.During construction of container responsible for managing source code (we call this side workspace-agent) we deploy there all the services necessary for:- managing project metainformation and remote file system: that is what we call Che Project API- APIs for project type specific calls, provided by specific extensions, such as in case of java: JDT based codeassistant, autocompletion and other intellisense/editor related calls (so far we do not have generic abstractions for it so really java specific things).So before we go to more specifics, let me ask you if you goal is rather:1/ to reuse some of yours existed Eclipse plugin Java code to make it accessible remotely2/ same as #1 but not necessary Eclipse code dependent (to make extension using Java from scratch)3/ same as #2 but using Erlang, not Java services (Erlang based REST API for "smart editor")ThanksGennadyOn Tue, Feb 2, 2016 at 11:40 AM, Vlad Dumitrescu <vladdu55@xxxxxxxxx> wrote:_______________________________________________From: Tyler Jewell <tyler@xxxxxxxxxxx>
For your points:
1. I have cc'd the engineers that have spent the most time either
architecting the plug-in framework, and / or using it to build our plug-ins
especially the Java / Maven ones.
2. As a general rule, the objective is to be able to plug existing
libraries for various languages to run natively within the workspace, and
then to create Che plug-in wrappers around those libraries, turning them
into RESTful services. This is what was done for Java, and some _javascript_.
I believe that our abstractions are clean here, but I imagine that the
cleanliness of the abstractions themselves get stronger as more languages
are added in. I am just the project lead, not the architect - so those
CC'd can provide better descriptions.
Could you share a little about which languages you'd like to add support
for?
Tyler JewellHi Tyler,Thanks for your answers.I am currently the developer for erlide, the Eclipse support for Erlang. The evolution of the architecture has been from a fully Java implementation towards using an Erlang runtime as a backend for the IDE services. My biggest architectural problem has been coming up with a remote API, hopefully a generic one. I still don't have a good one and when I read about Che, I realized that its APIs might be just what I needed.Also, many Erlang users are using it for developing web applications and they would benefit from being able to use Che instead of the regular Eclipse, as it's better suited for web development, so I am also looking at providing Erlang support for Che.best regards,Vlad
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.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://dev.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://dev.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://dev.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://dev.eclipse.org/mailman/listinfo/che-dev