Hi Doug,
Eclipse Target Management v1 was RSE.
Target Management v2 is the Target Explorer – which happens to live in the TCF project but is independent of the TCF protocol.
We’ve learned from some mistakes of the past and came up with a very lightweight and flexible solution.
In fact, when you install Terminals from the Eclipse Marketplace into Luna:
http://marketplace.eclipse.org/content/tcf-terminals
attached is what you get – terminals plus some infrastructure for dealing with properties, persisting them, handling events
and UI widgets.
We believe that this is a very lightweight and extremely flexible target management system.
Are you sure you want to invent Target Management v3 from scratch ?
I don’t think we need to fight around what lives in which project.
The real questions to answer should be the technical ones around why you think you need something new.
Thanks,
Martin
--
Martin Oberhuber, SMTS
/ Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
Actually that’s technically incorrect. TM has one set of committers and there are no restrictions on what they can commit to other
than social ones. Committers can veto changes and if that happens we can ask some harder questions about motives. Be pretty weird to fork the Terminal in the same project.
At any rate, Greg and I had an offline discussion and I think we have a pretty good plan. To be open and to solicit feedback, we
plan on bringing the org.eclipse.remote framework to the TM project. And we will build up an awesome target management system based on that which will include Terminal support, a File System browser, the LaunchBar and a View for central access to the connections,
all extensible to handle different connection types and services with minimal effort. Keep it simple is our motto.
It’s important that the TM parts continue to support the TCF Terminals View, but it’s also important that TM remain a +1 offset project
with minimal dependencies since the plan is to have lots of things build on it. Shouldn’t be too hard to keep that balance. In fact we even talked about whether it makes more sense for the Terminal to be an editor part so it can persist between perspectives.
We’ll see.
I think this is a great opportunity to bring together the various communities that deal with remote computing resources be they high
performance compute clusters, virtual machines out in the cloud, and devices be they industrial embedded systems or you’re little Arduino boards. We certainly hope others will join us and help make a Eclipse IDE for these important use cases.
