Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Next Meeting?

On Mon, Mar 28, 2016 at 3:25 AM, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:

On 25 Mar 2016, at 9: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

About good generic base components for the text editor I find Tom Schindl work at https://github.com/BestSolution-at/code-swt
interesting. Adds the for years needed generic but extendable text editor to SWT that Eclipse could really benefit from
and it has the notion of services (internally or externally) that can be added to it allowing for a much faster development of
extensions but also to allow much more codesharing of basic functionality.

Cool. I really need to take a look there as well. 

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

of course - but why let you limit yourself to an approach that takes several man years to get even basic
support for a language ?

I'm spending some time reworking my cdtdoug.ca web site and am building a hand rolled CMS (yes I know there's a million out there and when I'm done there will be a million and one). I'm using React.js for my front end framework and I would love to have JSX support in Eclipse which I'm using to build the vert.x Java back end. The front end is small so I don't need "intellisense", I just want syntax highlighting and bracket matching. Once I get fancier, then sure it may help, but I need the basics now, not in "several man years".
 

Eclipse supporting both models would be a win for all IMO.

We need to break our habit of always demanding the best when I'm not sure I users really care. Sublime and the like are interesting to them because it supports so many languages now. No "intellisense", but enough of what they need. There's no reason why we couldn't have a competitive offering with Eclipse.
 

/max


Thanks Max!

Doug. 

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@xxxxxxxxxjayjaybillings@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@xxxxxxxxxmlippert@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@xxxxxxxxxxxxjohn@xxxxxxxxxxxx:

On Wed, Mar 16, 2016 at 4:16 AM, Oberhuber, Martin Martin.Oberhuber@xxxxxxxxxxxxxMartin.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@xxxxxxxxxxxeclipse.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@xxxxxxxxxxxemo@xxxxxxxxxxx to request removal.


eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.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@xxxxxxxxxxxemo@xxxxxxxxxxx to request removal.

--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings


eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.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@xxxxxxxxxxxemo@xxxxxxxxxxx to request removal.


eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxeclipse.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@xxxxxxxxxxxemo@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.

/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.


Back to the top