Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tm-dev] o.e.remote 

Summary of concerns:
1) There's a heavy dependency on CDT in PTP. It feels strange to have basically a remoting or terminal framework in a repository so heavily tied to CDT. Also there's no clear separation in the ptp repository of code that requires CDT and code that doesn't.
2) RSE seems to be providing a not insignificant portion of the remote functionality as evidenced in the Remote Development -> Connections page supporting RSE. It would seem removing RSE would also decrease the usefulness of PTP as currently implemented.
3) As evidenced by Doug's recent posts, it's clear the interfaces are large and generic. It's possible they could be refactored into smaller ones relevant to individual systems, but I don't see how that'd be better than just using RSE?
4) What were the primary goals that org.eclipse.remote were trying to solve, that was not solvable in RSE?
5) Assuming RSE is removed, what exactly is on the plan of org.eclipse.remote / PTP to match the functionality of RSE/TM? And what's more, how exactly will this be better than what RSE / TM currently provides? Is the scope limited to specific usecases that fit what PTP needs? Or will they be more generic like RSE / TM were?
6) This is a specific question to Doug, but, I see that you're attempting to make what is basically an Arduino connection type. Have you tried to make one for RSE / TM before? Was it so difficult that you actually see huge (probably breaking) changes to an existing API as a more viable solution than working within the RSE / TM code and re-using the various already-completed subsystems?
7) I would like to know what exactly would need to be done by people who actually like RSE to ensure that it continues to survive through Mars? Responses here should include the bare-bones (We need someone to push the 'go' button) to the more abstract "survive as a project" suggestions, like what is RSE missing that is thwarting adoption?
My concerns are that trying to force PTP to be the new RSE will most likely be an incomplete hack-job that will get half-way there, without any clear over-arching design that makes an API actually useful in the future. Quick changes to force an API to do something it wasn't designed to usually end in tragedy, but not until after a lot of work was expended in the process. It's also already been declared that ftp and windows server support are not on the roadmap at all for PTP and o.e.remote, and, by looking at the codebase, would require significant architectural changes anyway.
I would really like to hear more about what people find troubling about RSE that they'd rather throw their weight into rewriting and breaking API in org.eclipse.remote to create some ill-fated chimera rather than put the energy into maintaining a functioning set of plugins that has a not-insignificant adoption rate, clear (and FULL-FEATURED) interfaces, a mostly easy to navigate workflow (connection name -> host -> system with choice of subsystem -> implementation) and a slightly overbearing UI.
I see no reason to replace a good API with a mediocre API that does less and waste energy in the process. If anything we should be taking this opportunity to make RSE more useful, identifying its pain points, and seeing if there's any support to actually fixing it. 

- Rob Stryker


On 12/01/2014 01:26 AM, Doug Schaefer wrote:

Cool, thanks Greg. I guess what I’m thinking is opening up remote beyond
what PTP has used it for and to make it a full replacement for RSE. The
view would list the connections. We could then add context menus to do
things like opening a file browser in an editor so you can drag and drop
files between remotes (including local).

However some connection types, like Arduino, don’t have remote file
systems at all, but I’d like to use other services, like the command
shell. This could be handled as easily as returning null when requesting
services that are optional.

The main thing I’m working on now is an Open Terminal item that would use
the command shell to provide the content. Might borrow some of the code
from the TCF terminals to make it work, especially for the local
connection.

I guess my main API ask will be to make things IAdaptable. I could then
add things to the API without changing any of the interfaces. It also lets
you hook up API to existing frameworks. It’s a technique that really
helped me with the LaunchBar. I’m finding other ways to make things work
for now though so we could clean things up for Mars. My focus on the
moment is to get this ready for Luna SR-2 when I plan to release the
LaunchBar that would use this for it’s target management.

Anyway, I’ll keep plugging along until I get something working. Meeting on
the 9’th sounds like a good time to hook up. If I have detailed questions,
maybe you and I can hook up off-line.

Doug.

On 2014-11-28, 7:41 PM, "Greg Watson" <g.watson@xxxxxxxxxxxx> wrote:


Hi Doug,

To address some of your questions:

There is already a preference page that shows all the connections (Remote
Development > Remote Connections). This could be easily turned into a
view, but we never felt is was necessary. Did you particularly want a
view?

The getCommandShell() API was added because we knew there would come a
time when someone would want one. However, PTP does not require a shell
currently, so there was no need to implement it. Contributions gratefully
accepted :-).

The schema requires filesystem access because our model is to target
Unix-like systems. i.e. we don’t currently ever intend support a remote
Windows client. However, I would be open to a schema that made this
optional, provided that it does not complicate the API significantly.

I’m certainly happy to discuss API changes, and in principal would have
no objections provided that they don’t complicate how the existing APIs
are used. One of our overriding principles is that there should be
minimal setup required by the user (e.g. anything more than a hostname,
username and password is discouraged). The use of a custom protocol is
only acceptable if it can be installed and configured automatically
without any user intervention.

I’m looking forward to seeing your fork, and would be happy to set up a
meeting to discuss this further. The next PTP developer meeting is
scheduled for 12/9 at 1pm EST, so this might work.

Regards,
Greg




On Nov 28, 2014, at 3:40 PM, Doug Schaefer <DSchaefer@xxxxxxx> wrote:

The ideas keep pouring out of my head. I’m really liking the o.e.remote.
Found a few surprises that might help us unify things.

One thing I found was the getCommandShell() method on IRemoteConnection.
My next bit of fun will be creating a TCF Terminal extension that will
hook that up to a terminal. First surprise though was that this method
isn’t implemented by either Jsch or Local. Should be easy enough though.
Just figure out the shell and fire it up with a remote process builder.

I am just starting out my Android IRemoteConnection. It doesn’t do much,
there’s no file system to access (which begged the question why the
schema
is mandatory). But I do have a command shell I could create for it to
give
it access using that same terminal extension.

Which then begs the question why I would need any of the other TCF
extensions if we could base them all off of
IRemoteConnection.getCommandShell().

Anyway, I’ll probably post my fork of o.e.remote up to github so you can
see what I’m doing (and so I can build the Arduino and Momentics IDEs
based on this work). Might be good to set up a meeting to discuss some
of
this as well. I have questions about how things were done and if people
mind me changing them.

Have a great weekend.
Doug.

On 2014-11-27, 3:04 PM, "Doug Schaefer" <dschaefer@xxxxxxx> wrote:


Also, as I work on adding the API I need to build a remotes view, I’m
finding I have to add methods to the existing interfaces, which breaks
the
API. I could create version 2’s of the interfaces, but that’s going to
be
painful.

If we move to 2.0, we need to make sure we don’t have people extending
these interfaces who would be surprised by the breakage in Luna SR-2
(where I really want to ship this stuff).

Thoughts?
Doug.

On 2014-11-27, 10:50 AM, "Doug Schaefer" <dschaefer@xxxxxxx> wrote:


Hey Greg,

Started looking at using the o.e.remote plug-ins as the foundation of
the
remote support in the LaunchBar. I’m starting to really like this
idea.
As
discussed, it needs a View to show all the current connections. I also
need the list of current connections to show in the Launch Targets
selector in the launch bar.

Is there API for that? I didn’t find it, and the current APIs look
like
they were designed to support remote connection types and not have UI
of
it’s own. But I don’t think we’re far from that and I’d be happy to
contribute there.

BTW, I continue the discussion here on the TM list. I think
o.e.remote’s
proper home is probably here. I’m starting to wonder if TCF belongs
here
too. Put everything remote/target related into a single project. Just
a
thought.

Cheers,
Doug.

On 2014-11-25, 3:34 PM, "Doug Schaefer" <dschaefer@xxxxxxx> wrote:


We’ll see how my remote stuff works out. I’m going to start working
on
it
tomorrow.

Now, the Launch Bar is not CDT specific. The remote targets are not
CDT
specific either. In fact, I’d like to be able to build a remote Java
launch using the same code. I guess it’s a question of how we bring
all
these things together. In fact, I’d love it if the TCF Terminals View
wasn’t tied to TCF so we could put it in with this pile. And maybe
they
all should be in a project that focuses on the management of targets
;p.

I imagine if we had the commons project set up, we’d be doing a lot
of
this there. The relationships are pretty complicated and I’ve been
kind
of
ignoring them so I can just build it and get things going. But I will
make
sure I minimize the dependencies on CDT to just actual C/C++ things.

On 2014-11-25, 2:56 PM, "Greg Watson" <g.watson@xxxxxxxxxxxx> wrote:


Is your Targets View CDT specific, or is it something that might be
useful to other projects? If the latter, then maybe it should go
into
org.eclipse.remote?

Greg

On Nov 25, 2014, at 2:13 PM, Doug Schaefer <DSchaefer@xxxxxxx>
wrote:


OK, here we go. I looked at the Target Explorer when considering a
Targets
View for the LaunchBar and found it to be too flexible and too hard
to
extend. I didn’t see what it bought me over the standard jface
Content/Label providers. As such, I have created my own Targets
View
for
the launch bar and will be adding things like file and process
browsers
to
it. This will be another alternative to replace RSE with the
advantage
of
being tied nicely to the launch bar for Remote launches.

You can see this work in the CDT launch bar plug-ins and the
Arduino
IDE I
am building out at github.com/dschaefer/wascana. More when I make
more
progress there.

Note that this is all towards my work on supporting remote launches
in
the
CDT using the org.eclipse.remote plug-ins and the jsch stuff in
particular. This is something CDT should have had a long time ago.
And
with the LaunchBar making it easy to add remote targets and then
co-ordinating launch configurations to launch for them, it’s time.
I
am
working to get this done by the 8.6 CDT release in February.

Doug.

On 2014-11-25, 4:22 AM, "Stieber, Uwe" <Uwe.Stieber@xxxxxxxxxxxxx>
wrote:


Hi,


After having written a fair bit of code that extends RSE I do
certainly
agree with
others that it is not an ideal model, and so I am also interested
in
what a
migration path looks like and would be interested in contributing
work
there.
Like Uwe said in another follow on, maybe that looks like adding
the
SSH/SFTP
to Target Explorer or something.  In practice our usage has
tended
to
mash-up
different underlying technologies on one connection.  In effect
we
are
using
SSH/SFTP for file system access and the terminal as well as the
ability
to spawn
remote processes and redirect stdio.  Then we additionally use
unrelated web
services on the same target to provide other objects in the tree
(e.g.
power on
a VM, etc.).  So all that to say, a more flexible model in the
tree
would be
great.   I know very little about it, but it does appear that the
new
org.eclipse.remote API provides much of what we need minus a
terminal,
but I
am not sure how that fits into an "explorer" view of one flavor
or
another.

The "Target Explorer" had been designed with most possible
flexibility
and extentability in mind. In fact, the "System Management" view,
which
is Target Explorer equivalent to the "Remote Systems" view, is
simply
an
instantiation of the Eclipse Common Navigator framework. You have
the
total flexibility and contribution possibilities of a Common
Navigator.
If you have ever done a contribution into the Eclipse Project
Explorer,
you can do a contribution into the "System Management" view too.
You
basically have the full control of all the views content right
from
the
root nodes.

Right now, we do have a core Target Explorer + very complete TCF
based
extensions for remote filesystem browsing and editing, remote
process
launch and monitoring and debugging. The TCF project also hosts
the
new
"Terminals" view bringing a lot of always asked for enhancements,
like
the support for local terminals on both Unix and Windows. This new
"Terminals" view is the only maintained one and should be included
in
all
packages and offerings used to include the outdated "Terminal" or
"RSE
Terminals" views. And the effort to get there is basically what
triggered
the thread here.

What we would like to see is a core Target Explorer +
org.eclipse.remote
based extensions for SSH/SFTP remote filesystem browsing and
editing
as
well as remote process launching an monitoring. That's definitly
the
most
desired contribution we would be very exited to see happening.

Best regards, Uwe :)






-----Original Message-----
From: tm-dev-bounces@xxxxxxxxxxx
[mailto:tm-dev-bounces@xxxxxxxxxxx]
On
Behalf Of Aaron Spear
Sent: Montag, 24. November 2014 18:03
To: TM project developer discussions; Michael Scharf
Subject: Re: [tm-dev] Master branch is TM 3.7?

Hi again Doug et all,

Yes, certainly many are enjoying the fruit of the TM committers
vision
and
labor, and we owe you all a very big debt of gratitude.  Thanks
for
your
seemingly endless enthusiasm, energy and commitment to making
great
software.  I do of course agree that it is not reasonable for my
company or
anyone else to expect you all to continue to maintain RSE out of
the
goodness
of your heart (however good it may be, there is only so much a
human
can do!)

Assuming that we or others with a vested interest are willing to
step
up and
help, what would that look like?  It would appear that anyone
that
is
going to
help is not likely to be a current committer on the project since
as
you said
there is no one left to do this.  I am not sure how that would
work
to
have
myself or someone else from VMware or Redhat etc. to jump in for
maintenance for the next release perhaps?

After having written a fair bit of code that extends RSE I do
certainly
agree with
others that it is not an ideal model, and so I am also interested
in
what a
migration path looks like and would be interested in contributing
work
there.
Like Uwe said in another follow on, maybe that looks like adding
the
SSH/SFTP
to Target Explorer or something.  In practice our usage has
tended
to
mash-up
different underlying technologies on one connection.  In effect
we
are
using
SSH/SFTP for file system access and the terminal as well as the
ability
to spawn
remote processes and redirect stdio.  Then we additionally use
unrelated web
services on the same target to provide other objects in the tree
(e.g.
power on
a VM, etc.).  So all that to say, a more flexible model in the
tree
would be
great.   I know very little about it, but it does appear that the
new
org.eclipse.remote API provides much of what we need minus a
terminal,
but I
am not sure how that fits into an "explorer" view of one flavor
or
another.

thanks again,
Aaron

-----Original Message-----
From: tm-dev-bounces@xxxxxxxxxxx
[mailto:tm-dev-bounces@xxxxxxxxxxx]
On
Behalf Of Doug Schaefer
Sent: Friday, November 21, 2014 8:22 PM
To: TM project developer discussions; Michael Scharf
Subject: Re: [tm-dev] Master branch is TM 3.7?

Hi Aaron, good to hear from you again. I’m glad that Vmware, and
othercompanies, are enjoying the fruits of the hard work that the
RSE
team
hasput in over the years. But as I’m sure you’re aware, these
haven’t
beencharitable donations, and those who have contributed are now
gone.
Theresno one left to do this for you. If you and others want it
alive,
you needto
step up and invest in it.Doug.On 2014-11-21, 7:30 PM, "Aaron
Spear"
<aspear@xxxxxxxxxx> wrote:>Hi TM friends,>>I am a little unclear
on
what
is being proposed here, but it sure looks>like you are talking
about
a
possible
end of life for RSE as we know it?>>I think you would probably be
surprised just
how many companies and>others are using RSE downstream.  VMware
for
instance is using it for>file system, terminals, and other custom
services for a
number of>developer SDK's targeting our main products (including
ESX
hypervisor,>vCenter, vCenter Orchestrator and others).  We
actually
have a
subsystem>and such to support connecting to Windows boxes using
CIFS
that
we were>thinking about contributing.  RSE certainly has its
warts,
but
it
still>has a place in our product lines and VMware would like to
keep
it
around.>
I suspect there are other companies in this camp too.  Heck I
find
it>generally
useful to have around while I am doing web development so that>I
can
easily
edit remote configuration files in my local
eclipse>seamlessly.>>Are
you
looking for new blood to jump in and maintain it?>>best
regards,>Aaron
Spear,
VMware>>>-----Original Message----->From:
tm-dev-bounces@xxxxxxxxxxx
[mailto:tm-dev-bounces@xxxxxxxxxxx] On>Behalf Of Doug
Schaefer>Sent:
Thursday, November 13, 2014 9:13 AM>To: Michael Scharf; TM
project
developer discussions>Subject: Re: [tm-dev] Master branch is TM
3.7?>>We
quickly discussed this on the architecture council call and it
appears>there are
commits happening, but it¹s not being picked up by the portal>at
the
moment.
So it¹s not quite dead yet :). But certainly at issue.>>Doug.>>On
2014-11-13,
11:10 AM, "Michael Scharf" <eclipse@xxxxxxxxx> wrote:>>>+1 let it
die
unless
someone steps up...>>>>Michael>>>>On 2014-11-13 15:52, Greg
Watson
wrote:>>> I¹m fine with this if we have everyone¹s agreement.
Committers on
the>>>project are:>>>>>> € Anna Dushistova>>> € David
McKnight>>> €
Greg
Watson>>> € Kevin Doyle>>> € Martin Oberhuber>>> € Michael
Scharf>>>
€
Uwe Stieber>>>>>> Assuming Martin and Uwe have already agreed,
I¹d
like
to
have a +1>>>from Anna, David, Kevin, and Michael before
proceeding.
I
don¹t
think>>>we can proceed unless we have at least a majority of
committers
voting>>>+1.>>>>>> If we go ahead with archiving TM, I suggest we
use
Luna
SR2 for the>>>final release and withdraw from Mars.>>>>>> Here¹s
a
summary:>>>>>> 1. Announce TM change proposal to cross-project a.
Final
release of>>> TM 3.7 with Luna SR2 b. TM to withdraw from Mars 2.
Agreement from>>> TCF project to host Terminal 3. Approval from
PMC
for
restructuring>>> review 4. Restructuring review to move Terminal
to
TCF
5.
Approval>>> from PMC for termination review 6. Termination review
7.
TM
is>>> archived>>>>>> Is this agreed? Anybody not in
agreement?>>>>>>
Thanks,>>> Greg>>>>>>>>>>>> On Nov 13, 2014, at 6:13 AM,
Oberhuber,


Martin>>><Martin.Oberhuber@xxxxxxxxxxxxx>>><mailto:Martin.Oberhube
r@
windriver.com>>>>>wrote:>>>>>>> Ok.>>>> If the plan of archiving
TM
solidifies, we¹ll need to inform>>>>cross-project about that.>>>>
Greg
are you
going to do that ?>>>> I could imagine that there will be a
couple
downstream
projects who>>>>won¹t be happy about TM being archived, so better
announce
early.>>>> 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*Stieber,
Uwe>>>>*Sent:*Thursday,
November 13, 2014 9:25 AM  *To:*TM project
developer>>>>discussions>>>>
*Subject:*Re: [tm-dev] Master branch is TM 3.7?>>>> Hi
Martin,>>>>
Sounds
like a plan to me.>>>> Best regards, UweJ>>>> *From:*tm-dev-


bounces@xxxxxxxxxxx>>>><mailto:tm-dev-bounces@xxxxxxxxxxx>[mailto:
tm
-
dev-bounces@xxxxxxxxxxx>>>>]*O>>>>n Behalf Of*Oberhuber,
Martin>>>>
*Sent:*Donnerstag, 13. November 2014 08:59  *To:*TM
project>>>>developer
discussions>>>> *Subject:*Re: [tm-dev] Master branch is TM
3.7?>>>>
So,
following sounds like a plan:>>>> 1.Terminal is moved from TM to
TCF
(that¹s
where the active>>>>committers>>>>are)>>>> 2.We need one more
release
of
TM (Luna SR2 or Mars) such that we can>>>>clean up the
dependencies
on
the
Terminal  3.After that, TM can be>>>>archived as a project.>>>>
Do
the
committers agree ?>>>> 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>>>>]*O>>>>n Behalf Of*Stieber, Uwe>>>>
*Sent:*Thursday, November 13, 2014 8:03 AM  *To:*TM
project>>>>developer
discussions>>>> *Subject:*Re: [tm-dev] Master branch is TM
3.7?>>>>
Hi
Greg,>>>> Well, I can speak only for Terminal and the Terminal is
definitely>>>>under active development. There might be just 2
active
committers>>>>left, myself and Martin Oberhuber from time to
time,
but
we
still do>>>>changes and we still need releases.>>>> I would be OK
to
move out
the Terminal from the TM project but the>>>>proposed common
project
where
things like the Terminal could live>>>>does not exist yet. I¹m
also
fine with
moving the Terminal widget to>>>>the TCF project container, but
that¹s
something Martin Oberhuber>>>>needs to decide.>>>> For the
Terminal,
the
main complains are not necessarily bugs at>>>>this point of time,
the
main
complains are about the fact that you do>>>>have multiple
Terminal
views in
Eclipse once RSE is installed. 2>>>>views are at least deprecated
and
only  the
³Terminals² view provided>>>>from the TCF project is maintained
and
where
new features requested>>>>by the users are added. We have to get
the>>>>2
other Terminal views out of Eclipse to stop the user confusion.
The>>>>plan for
doing this is  outlined below, but this work does have
some>>>>effect
on EPP
packages. I can do everything outlined below, but I>>>>don¹t know
how
to get
the EPP packages updated to include the correct>>>>features.>>>>
The
cleanup
of the multiple Terminal views should happen for the>>>>Mars
release.>>>>
Regarding the committer meetings, at least for me time is
limited>>>>and
discussing things here instead of a shared conference call
is>>>>easier
to
manage.>>>> Thanks, Best regards, UweJ>>>> *From:*tm-dev-


bounces@xxxxxxxxxxx>>>><mailto:tm-dev-bounces@xxxxxxxxxxx>[mailto:
tm
-
dev-bounces@xxxxxxxxxxx>>>>]*O>>>>n Behalf Of*Greg Watson>>>>
*Sent:*Mittwoch, 12. November 2014 23:01  *To:*TM project
developer>>>>discussions>>>> *Subject:*Re: [tm-dev] Master branch
is
TM
3.7?>>>> Hi Uwe,>>>> I¹m not sure of the plans at this point.
I¹ve
asked this list
about>>>>the 3.6 version a couple of times but received no reply.
I¹ve
also>>>>invited everyone to the PTP developers conference call to
discuss>>>>plans, but no one from TM ever  attended. At this
point,
I¹m
assuming>>>>that the current release is the final release for
TM.>>>>
I¹m not a
developer on the project, so I don¹t know what anyone¹s>>>>plans
are
unless
they let me know. Also, developer¹s will need to>>>>step up and
update
the
project plan, documentation, and anything else>>>>that needs to
be
done. I can
fix the  outline of the plan, but>>>>someone else will need to
fill
in
the details.
Finally, we need>>>>people to test the builds before they are
released,
or we
can¹t say>>>>we¹re meeting Eclipse quality. This didn¹t seem to
be
happening
for>>>>the SR1 release.>>>> Regards,>>>> Greg>>>> On Oct 30,
2014,
at
5:43
AM, Stieber, Uwe
<Uwe.Stieber@xxxxxxxxxxxxx>>>><mailto:Uwe.Stieber@xxxxxxxxxxxxx>>
wrote:>>>>>>>> Hi Greg,>>>> Can you confirm that I¹m right in
assuming
that
the master branch is>>>>leading to the TM 3.7 release? When will
it
be
released? I¹ve checked>>>>the TM project pages


undereclipse.org/tm>>>><https://urldefense.proofpoint.com/v2/url?u
=h
t
t
p
-
3A__eclipse.org_tm&d=A>>>>AIF-g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-
YihVMNtXt-
uEs&r=IoX6lQ05T8ggojuUJ>>>>t27Ff7wSZqFOe_BW7zihIF6LNA&m=g5KNm0_rR
Dpsx8IAZTePBHXZbMdB1kZoo_V--
5hcjJ>>>>g&s=J15p7KqGXLIYotI2Ci3Ci_PI83Q9u9gs6TneSPJjhDk&e= >,
but
this
pages>>>>are not up to date.>>>> If master is leading to the 3.7
release, I
would like to change at>>>>least the TM Terminal feature version
numbers
accordingly. Also I>>>>want to tackle a few Terminal related
releasing
issues
we keep>>>>pushing ahead of us for a long time now.>>>> Not sure
if
you
need
to announce them in some project lead meeting.>>>> 1.Deprecation
of
unused
or no longer supported features  a.Take out>>>>the
o.e.tm.terminal.view
and
the o.e.tm.terminal.local from the build>>>>and repositories
b.Move
the
source of this features to>>>>terminal/deprecated folder to keep
the
source
around for reference>>>>c.Remove the o.e.tm.terminal.core.sdk
feature
as
without the>>>>terminal.view feature, the usual SDK feature is
the
same
as
the>>>>core.sdk feature  2.Work on replacement for
org.eclipse.rse.terminal>>>>feature  a.Remove this feature from
the
org.eclipse.rse feature>>>>b.Create an replacement providing the
same
entry
points from the RSE>>>>System Explorer as the
org.eclipse.rse.terminal
plug-in
does but use>>>>the newer and maintained TCF Terminals view. The
new
RSE
terminal>>>>feature will be provided by the  TCF project like the
TCF
based
file>>>>system and process RSE contributions.>>>> All effort is
related
to
address the many complains about having up>>>>to>>>>3 different
terminals
views available in Eclipse. Final goal is to>>>>bundle all
terminal
related effort,
bugfixing and feature>>>>development, into the superior TCF
Terminals
view.>>>> Best regards, UweJ>>>>
_______________________________________________>>>> 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://urldefense.proofpoint.com/v2/url?u=https-

3A__dev.eclipse.org_>>>>mailman_listinfo_tm-2Ddev&d=AAIF-
g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-Yi>>>>hVMNtXt-
uEs&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=g5KNm0_rR>>>>
Dpsx8IAZTePBHXZbMdB1kZoo_V--5hcjJg&s=e-
Iu6cCQbIlNvZ8doJvrVmB13sZh4QSJ>>>>LfLhqkD8KPM&e=
_______________________________________________>>>> 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://urldefense.proofpoint.com/v2/url?u=https-

3A__dev.eclipse.org_>>>>mailman_listinfo_tm-2Ddev&d=AAIF-
g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-Yi>>>>hVMNtXt-
uEs&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=g5KNm0_rR>>>>
Dpsx8IAZTePBHXZbMdB1kZoo_V--5hcjJg&s=e-
Iu6cCQbIlNvZ8doJvrVmB13sZh4QSJ>>>>LfLhqkD8KPM&e=>>>>>>>>>>>>
_______________________________________________>>> tm-dev mailing
list>>> tm-dev@xxxxxxxxxxx>>> To change your delivery options,
retrieve
your
password, or>>>unsubscribe from this list,
visit>>>https://urldefense.proofpoint.com/v2/url?u=https-
3A__dev.eclipse.org_m>>>ailman_listinfo_tm-2Ddev&d=AAIF-
g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihV>>>MNtXt-
uEs&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=g5KNm0_rRDps>

x8IAZTePBHXZbMdB1kZoo_V--5hcjJg&s=e-

Iu6cCQbIlNvZ8doJvrVmB13sZh4QSJLfLh>>>qkD8KPM&e=>>>>>>>___________
____________________________________>>tm-dev mailing list>>tm-
dev@xxxxxxxxxxx>>To change your delivery options, retrieve your
password, or
unsubscribe>>from this list,
visit>>https://urldefense.proofpoint.com/v2/url?u=https-
3A__dev.eclipse.org_ma>>ilman_listinfo_tm-2Ddev&d=AAIF-
g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMN>>tXt-
uEs&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=g5KNm0_rRDpsx
8I>>AZTePBHXZbMdB1kZoo_V--5hcjJg&s=e-
Iu6cCQbIlNvZ8doJvrVmB13sZh4QSJLfLhqkD8>>KPM&e=>>_________________
______________________________>tm-dev mailing list>tm-
dev@xxxxxxxxxxx>To change your delivery options, retrieve your
password, or
unsubscribe>from this list,
visit>https://urldefense.proofpoint.com/v2/url?u=https-
3A__dev.eclipse.org_mailm>an_listinfo_tm-2Ddev&d=AAIF-
g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
uE>s&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=g5KNm0_rRDps
x8IAZTePBHXZ>bMdB1kZoo_V--5hcjJg&s=e-
Iu6cCQbIlNvZ8doJvrVmB13sZh4QSJLfLhqkD8KPM&e=>____________________
___________________________>tm-dev mailing
list>tm-dev@xxxxxxxxxxx>To
change your delivery options, retrieve your password, or
unsubscribe>from this
list, visit>https://urldefense.proofpoint.com/v2/url?u=https-
3A__dev.eclipse.org_mailman_listinfo_tm-
2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
uEs&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=u3SMWFMuLdu2
19uG9W6Cjc5VxLeeRAjS0UBKKtixKaU&s=-
3lWJClgSsIz95Gg__igLfTHEiyMBjoNVNQyts6XeGg&e=
_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from
this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-
3A__dev.eclipse.org_mailman_listinfo_tm-
2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
uEs&r=IoX6lQ05T8ggojuUJt27Ff7wSZqFOe_BW7zihIF6LNA&m=u3SMWFMuLdu2
19uG9W6Cjc5VxLeeRAjS0UBKKtixKaU&s=-
3lWJClgSsIz95Gg__igLfTHEiyMBjoNVNQyts6XeGg&e=
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

Back to the top