Hi,
We will keep RSE building and will also have a repository for it. If it is a separate one of if we have a single repository for all, that’s still to decide.
But we wont drop building RSE J.
I guess with “TM Core” Martin refered to Terminal, Launchbar, o.e.remote and what else you want to have.
Best regards, Uwe
J
From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
Sent: Dienstag, 20. Jänner 2015 16:17
To: TM project developer discussions
Subject: Re: [tm-dev] Unifying the Eclipse Terminal
I’m not sure we have the RSE thing figured out, do we? Did someone step up to do builds of it.
I’m also not sure what TM Core is. Other than the Terminal widget, what else do we need going forward?
+1 for separating TM Core from RSE. Don’t know if we need a separate git repository for it, but being able to release TM Core on a different speed than RSE
in maintenance mode definitely make sense.
Best regards, Uwe
J
Hi Doug,
What is your time horizon for “I will be borrowing from the local terminals
implementation to implement the command shell service for the Local connection type” ?
We are committed to doing the dependency cleanup such that Eclipse gets a single Terminal View that matches all needs, but since this comes on short notice
we have some other work to finish before we start.
Do you feel that you depend on our work in any way ? What can we do to best help here in the next 6 weeks (taking Luna SR2 as an arbitrary milestone, although
our work will be relevant for Mars only if I got the Community demand right) ?
On a related note, if we bring such a core piece of technology into TM as a container, we feel that the build support for those TM Core Pieces needs to improve.
As far as we know, there are still some manual steps promoting RSE builds. Would it make sense getting a separate Git Repo / Hudson Job / Build Infrastructure for those TM Core Components that we are talking about ? Such that we can rebuild those core pieces
quickly on self-service Hudson if we need.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
I still have concerns over the TCF Terminal. While it may be superior to the old terminal view, it might not be the best ever. I think
the long term needs of a terminal for org.eclipse.remote demand a fairly simple solution since, as I mentioned previously, the settings are managed by the connection and users will use the new proposed Connections view to create and open terminals.
Having said that, I’m fine with bringing what you want from the TCF terminal down and replace the old terminal view. As you mention,
keep the dependencies and implementations simple. And I’ll see if we can adapt it to meet the o.e.remote requirements.
BTW, I will be borrowing from the local terminals implementation to implement the command shell service for the Local connection type.
And with o.e.remote’s support for SSH, we don’t really need Terminal support for individual connection types. Implementing these as connection services gives us flexibility to offer different visualization methods for the terminal in the future.
Yes, I support this and will help out where I can.
Wind River is committed to providing a unified Terminal to Eclipse users that provides the best possible user experience for everyone
rather than several point solutions.
We acknowledge that while the TCF Terminals View is superior, its existing dependencies and APIs make it look unnecessarily complex.
Having it live in the TCF Project made us take some services and infrastructure for granted since it was just there, although many of them aren’t strictly necessary. We therefore propose removing any unnecessary
/ confusing dependencies, updating APIs and documentation,and moving the TCF Terminals View to the TM Project for easier consumption.
We are convinced that the TCF Terminals View is superior to anything else, for the following reasons among others:
- There
is existing API to programmatically instantiate Terminals and manage/re-use them once they exist
- There
is existing Local Terminal / PTY integration including Windows
- There
is an existing solution for persisting previous Terminal sessions and easily restoring them (even without any target management on top of it – important for “plain local” or “plain SSH” use-cases)
Our goal is to enable contributors to add features easily as they need them, and we’re willing to engage with all stakeholders.
That said, we may need help from existing users (who have used or extended the legacy TM View) to collaborate on the new, unified solution.
The plan is making the new view org.eclipse.tm.terminal.view_4.0 or
similar and have it in EPP packages with Mars.
We are ready to invest our committer’s time, and we hope we can collaborate on getting a great solution.
If this is agreed as a general plan, we can come up with detailed next steps.
Martin Oberhuber, SMTS / Product Owner
– Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
|
