[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Next Meeting?
|
Hi,
As part of e(fx)clipse (yes I know JavaFX, ...) we've developed a
lightweight code-editor framework who aligns itself exactly into Martin
and Max are talking about.
To the editor everything is a service that can come from anywhere. It
can run inside your JVM, as an external process, talk to a cloud service
and as of today we have the following:
- Lexical-Syntax-Hightlighting (this is the only service we expect to
runside the same VM) but is not implemented as a set of Java-Classes
but loaded from a textual configuration file (no we don't use
textmates format but could implement that as well!)
- Auto-Complete
- Annotation-Support (Errors, Warnings,...)
- Hover-Support
- Code-Navigation
- Outline
The only important service missing yet is SemanticHighlighting!
As a proof-of-concept we have implemented support for Typescript
(Language-Service running in memory with j2v8) & Dart (Delegating to
Dart-Analysis-Server as external process), we decided to use
core-resources but directly use NIO.2 but targeting Core-Resources would
be possible as well.
I've mentioned this in all my talks lately that there's a trend that
every language comes with its headless infrastructure you can talk to:
- Typescript has the LanguageService (you can talk to it via ts-server)
and since 1.7 you can use that one for JS as well although tern is
still better
- JS has tern (or you an use Typescript-LanguageService)
- Dart has the Dart-Analysis-Server (what I've seen so far this the
most powerful headless infrastructure)
- Go / Rust have a headless server you can talk to
- .Net-Platform has a headless server built ontop of Roslyn
- For Java we have a PoC implemented ourselves (Built on JDT and
Core-Resources :-)
- ...
What we are looking at next is a protocol / message format we could
define allowing us to unify the communication with all those backends.
We are also looking into hooking our stuff onto Che workspaces server
but have not explored that (yet).
As noted in the initial sentence this is part of e(fx)clipse and
naturally we are (or rather our customers) applying it to
JavaFX-IDEs-Apps but 90% of the core-infrastructure is NOT bound to any
UI-Technology hence one can use it in an SWT world as well, if you
reimplement the SWT-bits required.
I've done a PoC for Max some weeks ago and we published the code at
github - https://github.com/BestSolution-at/code-swt - the PoC only
demonstrates auto-complete!
Tom
On 25.03.16 09:34, Oberhuber, Martin wrote:
> “External language API” sounds like a very interesting approach, and
> reminds me of a discussion we had in July last year –
>
>
>
> Michael Scharf had been proposing this sort of “external language API
> plugging into a smart text editor”
>
> https://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg02524.html
>
>
>
> But there were also counter arguments from Sven Efftinge and others
> saying that some “intellisense”
>
> Kind of features require deep integration of editor and the language
>
> https://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg02527.html
>
>
>
> Though Sven had said that the XText team was working on providing
> language services not only
>
> To the Eclipse IDE but also “external smart editors” …
>
>
>
> Thanks,
>
> Martin
>
> --
>
> *Martin Oberhuber*, SMTS / Product Owner – Development Tools, *Wind River*
>
> direct +43.662.457915.85 fax +43.662.457915.6
>
>
>
> *From:*eclipse.org-architecture-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] *On Behalf
> Of *Max Rydahl Andersen
> *Sent:* Thursday, March 24, 2016 10:35 PM
> *To:* eclipse.org-architecture-council
> *Subject:* Re: [eclipse.org-architecture-council] Next Meeting?
>
>
>
> Martin,
>
> +1000 (well, we've met and discussed this a few times already ;)
>
> One specific area I'm starting to see technology enabling this (besides
> flux) is the creation of "language api/runtimes".
> i.e. Visual Studio Code has their external services for doing content
> assist/validation via typescript, Che has their language runtimes,
> Angular.js using tern for the same and in Eclipse JSDT we've started
> allowing for similar approaches.
>
> Where every plugin is not necessarily running /inside/ the IDE but is
> instead externalised.
>
> Imagine if we allowed that for eclipse and could reuse visual studio
> code or even Che's language tools.
>
> Some of this stuff we could already do today (almost at least)
>
> But if we add in this notion of synchronised workspaces things becomes
> really interesting.
>
> Thats what I call the "micro service IDE" (and I hate that buzzword, but
> its actually applicable in this scenario ;)
>
> /max
>
> Hey Jay,
>
> since you are asking, I will share my thoughts here… :-) I will try
> to be as compact as possible.
>
> My assumptions:
> - desktop IDEs are not going away, they have high value and will
> continue to have high value for developers
> - cloud IDEs and environments will emerge more and more and provide
> additional/different value for developers and organizations
> - both don’t replace each other
> - developers don’t like to be forced into a cloud world, where there
> is nothing on their local machines anymore (for various reasons)
>
> My vision:
> Desktop IDEs and cloud-based IDEs and environments will both change
> in the future to form a unified working environment. In the end it
> doesn’t matter anymore whether you as a developer use your desktop
> IDE or a cloud-based IDE, a local text editor like Sublime Text or
> Visual Studio Code, an in-house GitLab instance or GitHub, use your
> laptop or your iPad for coding, deploying, triggering builds, etc.
> You will always have access to the exact same resources, the same
> state, the same projects, the same teams of people, etc. You will be
> able to start coding on your laptop, go to another room and continue
> coding on your iPad, invite people to take a look at your code from
> their iPhone, etc. You will use cloud resources to achieve all that
> and you will benefit from services running in the cloud for all
> that. This unified working environment will be the base for new
> emerging possibilities in the space of collaboration and for new
> technologies in the area of code analysis, code assist,
> machine-learning-backed coding support, and much more.
>
> The steps:
> People continue to use their Eclipse desktop IDE as they do today.
> Everything is local on their machines and they can do whatever they
> want. But things are synced with the cloud (on file level, while
> typing, whatever). Maybe this is where the Che distributed workspace
> concept joins the game. Maybe you startup Eclipse and some projects
> (or all) are coming from a distributed workspace server, but they
> continue to be copied to your machine. You will not notice the
> difference at all. (a step in this direction could be to offer Che
> workspaces in the workspace-selection-dialog at launch and get
> everything setup automatically). But using a Che distributed
> workspace is not enough here. Maybe it is a first step, but it is
> still far away from the unified and fully synced environment that is
> described in the vision above.
>
> Other front-ends are starting to appear and you can start to use
> them (in addition to your desktop IDE): A web editor running in the
> browser maybe, or a full-featured cloud-IDE, something like Eclipse
> Che that allows you to run stuff on a server machine somewhere, etc.
>
> Developers will decide what tool and UI they use for what task, but
> they always have access to the exact same resources, projects, text
> buffers, etc.
>
> In the background:
> Features that exist today in desktop IDEs will move or be copied
> into cloud services to make them available for other front-ends. The
> GitLab web ui will suddenly use a language-specific index to provide
> code navigation, the web editor will get comprehensive refactoring
> and content-assist support, and more. And services that are build
> for the cloud will be consumed back from the desktop IDE. For
> example a cloud service appears that analyzes code dependencies
> across your company or across projects at Maven central and provide
> you instant information about impact of the code changes in your
> editor, like making this chance in your source code will affect
> thousands of dependent projects/classes (beyond your workspace).
>
> The technology for all this is not rocket-science, but it is not
> there yet. And there are a lot of challenges to tackle on the way.
> The desktop IDE has a tremendous set of features that could be
> refactored and used in this setting way beyond the desktop IDE
> context, but it is not ready for this context yet. Eclipse Che has
> additional technology bits and pieces in place for some other parts
> of this vision, but is also not the exclusive answer to all this.
>
> Just a few thoughts… :-)
> Feedback welcome, as always.
>
> Cheers,
> -Martin
>
> Am 22.03.2016 um 00:17 schrieb Jay Jay Billings
> jayjaybillings@xxxxxxxxx <mailto:jayjaybillings@xxxxxxxxx>:
>
> +1
>
> Martin, I would be very interested in reading more about your
> vision in that separate thread you mentioned. Or we could keep
> it on this "Next Meeting?" thread of all things. ;-)
>
> Jay
>
> On Mon, Mar 21, 2016 at 3:43 PM, Martin Lippert
> mlippert@xxxxxxxxx <mailto:mlippert@xxxxxxxxx> wrote:
> Hey!
>
> (sorry for being late on this thread, just back from vacation)
>
> I agree to the comment from John regarding Flux. We were “too
> early” for others to pick up the idea and turn this into more
> than a prototype. As the main inventor of this technology I am
> particularly sad that I can’t work on this at the moment due to
> changed priorities (company-wise).
>
> Anyway, I still think that Flux addresses one of the main
> challenges that we have to solve in the future. I think we
> should have a very clear and precise answer to the question how
> to use desktop IDEs and cloud-based IDEs TOGETHER. They are not
> a replacement of each other. They overlap a lot, but they
> address different issues and different goals. Therefore, IMHO,
> the discussion should not be Eclipse IDE VERSUS Eclipse Che. The
> discussion could be how to combine both technologies to create
> something that can be used across those worlds and is truly
> unique. (I can elaborate more on that vision, but that might go
> beyond this thread.)
>
> I don’t care very much about the exact wording “next generation
> IDE”, maybe because I hear this mostly with my "marketing blurb”
> ear - and it can be interpreted in various ways anyway. I think
> we have a very unique chance to use the Eclipse IDE together
> with the technology from Eclipse Che to create something that
> combines those worlds and allows even more innovation in the IDE
> space. We should join forces across those project boundaries and
> work together towards such a greater vision.
>
> Just a few thoughts…
> -Martin
>
> P.S.: Regarding the future of Flux: I’ve seen quite a number of
> students being interesting in Flux for the Google Summer of
> Code. Maybe we can use that force to drive more innovation in
> this area this way. We will see.
>
> Am 16.03.2016 um 13:57 schrieb John Arthorne
> john@xxxxxxxxxxxx <mailto:john@xxxxxxxxxxxx>:
>
> On Wed, Mar 16, 2016 at 4:16 AM, Oberhuber, Martin
> Martin.Oberhuber@xxxxxxxxxxxxx
> <mailto:Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
> +1 for cloud workspace / desktop IDE for convergence.
>
> Wasn’t the Flux project exactly about that ?
>
> https://www.eclipse.org/flux/
>
> I see many committers but no recent commits, does anybody
> know recent status ?
>
> https://projects.eclipse.org/projects/technology.flux/who
>
> https://github.com/eclipse/flux/graphs/contributors
>
> Essentially there was a lot of interest in Flux but it
> didn't gather enough momentum to bring in contributors, and
> the project stalled. There is still a working prototype
> there, that anyone is welcome to pick up and continue. I
> really love its architecture and overall approach, and I
> think this model of blending cloud-based and desktop tools
> will eventually gain traction. It might have been a bit "too
> early" for the market on this idea.
>
> John
>
> ------------------------------------------------------------------------
>
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes
> internal to the Eclipse Foundation. To be permanently
> removed from this list, you must contact emo@xxxxxxxxxxx
> <mailto:emo@xxxxxxxxxxx> to request removal.
>
> ------------------------------------------------------------------------
>
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes
> internal to the Eclipse Foundation. To be permanently removed
> from this list, you must contact emo@xxxxxxxxxxx
> <mailto:emo@xxxxxxxxxxx> to request removal.
>
> --
> Jay Jay Billings
> Oak Ridge National Laboratory
> Twitter Handle: @jayjaybillings
>
> ------------------------------------------------------------------------
>
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes
> internal to the Eclipse Foundation. To be permanently removed
> from this list, you must contact emo@xxxxxxxxxxx
> <mailto:emo@xxxxxxxxxxx> to request removal.
>
> ------------------------------------------------------------------------
>
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes
> internal to the Eclipse Foundation. To be permanently removed from
> this list, you must contact emo@xxxxxxxxxxx <mailto:emo@xxxxxxxxxxx>
> to request removal.
>
> /max
> http://about.me/maxandersen
>
>
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
