Hi Greg,
>With the remote terminal service included, the terminal suddenly has a dependency to org.eclipse.remote, something not living in the TM >project, at least
not yet. Dependencies to an external project, something you and Doug S. have had complained about vehemently lately. >Never mind!
>
>If it’s any consolation, I did agonize over where it should go. If we put it in o.e.remote then it would bring in a dependency >on TM. In the end, it seemed to me that o.e.remote is providing a more “fundamental” service, so the dependency should >probably
go the other way. In a similar way to the TM dependencies on gnu.io and Jsch.
I’m fine with having the remote service based terminal connector living in the TM project and
I’m fine with having dependencies to other projects. Having dependencies to other valuable components of the Eclipse universe, even if not living in the same project,
I have no issue with that. Sometimes it is better to judge a component based on it’s functionality and the value it brings to the user and the Eclipse universe than judging the component based on it’s dependencies or even code style. Just my 2
cents.
Best regards, Uwe J
From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx]
On Behalf Of Greg Watson
Sent: Montag, 02. Februar 2015 20:53
To: TM project developer discussions
Subject: Re: [tm-dev] Remote terminal service
With the remote terminal service included, the terminal suddenly has a dependency to org.eclipse.remote, something not living in the TM project, at least not
yet. Dependencies to an external project, something you and Doug S. have had complained about vehemently lately. Never mind!
If it’s any consolation, I did agonize over where it should go. If we put it in o.e.remote then it would bring in a dependency on TM. In the end, it seemed to me that o.e.remote is providing a more “fundamental” service, so the dependency should probably go
the other way. In a similar way to the TM dependencies on gnu.io and Jsch.
Except from that, I don’t see any issue with this contribution.
One thing, are you open to get the feature renamed to have the feature(s) explicitly named “<id>.feature” or are you locked already to the current names of
the features? And we also would like to split up the features in a runtime feature (no sources) and an SDK feature (with sources). It reduces the download size of Eclipse based products bundling the Terminal.
I have no problem with adding “feature” to the ID, but none of the other terminal implementations have this. I was just using them as a reference.
I’ll add an SDK feature also.
|
