[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tm-dev] Unifying the Eclipse Terminal
|
On 20 Jan 2015, at 17:14, Stieber, Uwe wrote:
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 :).
That is great news (assuming I understand it correctly ;)
Does this mean we can get this
https://bugs.eclipse.org/bugs/show_bug.cgi?id=452899 rejected and
get TM (with RSE) back on mars release train ?
/max
I guess with "TM Core" Martin refered to Terminal, Launchbar,
o.e.remote and what else you want to have.
Best regards, Uwe :)
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?
Doug.
From: <Stieber>, Uwe
<Uwe.Stieber@xxxxxxxxxxxxx<mailto:Uwe.Stieber@xxxxxxxxxxxxx>>
Reply-To: TM project developer discussions
<tm-dev@xxxxxxxxxxx<mailto:tm-dev@xxxxxxxxxxx>>
Date: Saturday, January 17, 2015 at 4:49 AM
To: TM project developer discussions
<tm-dev@xxxxxxxxxxx<mailto:tm-dev@xxxxxxxxxxx>>
Subject: Re: [tm-dev] Unifying the Eclipse Terminal
+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 :)
From: tm-dev-bounces@xxxxxxxxxxx<mailto:tm-dev-bounces@xxxxxxxxxxx>
[mailto:tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Freitag, 16. Jänner 2015 22:56
To: TM project developer discussions
Subject: Re: [tm-dev] Unifying the Eclipse Terminal
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
From:tm-dev-bounces@xxxxxxxxxxx<mailto:tm-dev-bounces@xxxxxxxxxxx>
[mailto:tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Thursday, January 15, 2015 4:51 PM
To: TM project developer discussions
Subject: Re: [tm-dev] Unifying the Eclipse Terminal
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.
Doug.
From: Greg Watson
<g.watson@xxxxxxxxxxxx<mailto:g.watson@xxxxxxxxxxxx>>
Reply-To: TM project developer discussions
<tm-dev@xxxxxxxxxxx<mailto:tm-dev@xxxxxxxxxxx>>
Date: Thursday, January 15, 2015 at 9:48 AM
To: TM project developer discussions
<tm-dev@xxxxxxxxxxx<mailto:tm-dev@xxxxxxxxxxx>>
Subject: Re: [tm-dev] Unifying the Eclipse Terminal
Yes, I support this and will help out where I can.
Greg
On Jan 15, 2015, at 5:56 AM, Oberhuber, Martin
<Martin.Oberhuber@xxxxxxxxxxxxx<mailto:Martin.Oberhuber@xxxxxxxxxxxxx>>
wrote:
Dear all,
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.
Is everyone in ?
Thanks,
Martin
--
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<mailto: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
_______________________________________________
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
/max
http://about.me/maxandersen