|
For the Terminal, I’m envisioning the main workflow for o.e.remote is to start with the Connections view (the common navigator showing the o.e.remote connections) and create a new terminal or open an existing one from there. In that sense I don’t really
care about the settings dialog since the settings are actually all in the connection and managed by o.e.remote. And really the View could be anything since I still think you only want one view per terminal (especially if the open terminal functionality is
there to bring terminals into other perspectives). But, as always, I’ll be listening for user feedback on how well we’ve done with the experience.
And, yeah, I’m with Greg. Adding TCF as a dependency when you’re not using TCF is work I don’t really want to do or force adopters to do. TM needs to be a self contained target management system. That’s what it’s mandate is. We had that with RSE, and now
we’d like to do the same with o.e.remote.
Doug.
Hi Martin,
As I mentioned in a previous post, I see no compelling reason to force downstream projects to reimplement existing code for TCF Terminal when it is working perfectly well with the existing TM Terminal. PTP has no plans to do this, and it is not
in our (IBM’s) product plans either, as we have no intention of including additional TCF plugins in our product.
I will state it again here. As far as I can see, TCF Terminal is implemented on top of most of TM Terminal. The main difference appears to be new view and connection dialog implementations. The connection dialog is designed in a way that makes
more difficult to add custom widgets, so to provide the same functionality as TM Terminal would require a reimplementation of existing code. The new terminal view provides some additional features, but nothing that is compelling enough for us to warrant the
work that would be required to add support.
I agree that having a unified terminal implementation is a good long term goal. However the approach that has been taken so far has not involved discussion with any of the stakeholders or downstream consumers of the component. This is not acceptable
IMHO.
Since there is no urgency to this proposal, I would suggest that it would be a good topic for discussion at EclipseCon. Hopefully we could then arrive at a position that is acceptable to everyone.
Regards,
Greg
Hi Doug,
Of course you are free to use whatever components you find useful, and re-implement as you see fit.
On the other hand, we also want to avoid duplication in the Eclipse Universe, and ensure efforts are combined and focused.
FYI we could quite easily populate the LaunchBar’s target list with Target Explorer targets – see attached - so as long as “your own target management system”
doesn’t preclude us contributing Target Explorer’s targets, that part should be fine.
In terms of the Terminal though, I’d like to insist on unifying on a single Terminal implementation (like yourself have proposed a couple months ago). The TCF
Terminal can do everything that TM Terminnal could and much more. Uwe has invested quite some effort into making RSE’s terminal replacable for the Simultaneous Release:
And we’ll want the EPP packages to pick up TCF Terminals instead of RSE Terminal. The only question at this point is whether this can happen for Luna SR2 already
or whether it can only happen for Mars. Getting yet another terminal implementation would be counterproductive IMO.
We are happy to discuss improvement requests to the TCF Terminals, like allowing a View to be visible in all Perspectives or implementing an o.e.remote extension
point if that’s what you want to do. Contributions are most welcome here! I would suggest tracking these as Enhancement Requests against TCF Terminals – see also improvements we made recently, and the list of known enhancement requests:
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development
Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
You’re right they aren’t mutually exclusive. I’ve looked at the Target Explorer when making my decision on what TM system to use for the LaunchBar and didn’t see how it helped me. It’s
built to handle multiple TM systems and isn’t really a TM system itself. So why not give org.eclipse.remote its’s own UI build especially for it and keep things simple.
Adding IRemoteConnections to a common navigator view is pretty trivial. Adding my connection types into o.e.remote so that they show up in that view was pretty easy too. And if I implement
the proper services I’ll get Terminal, Launching, and File Browsing for free. What’s not to love. It’s almost like RSE done right. :)
Hi Doug,
I know o.e.remote and I like it for what it is.
There seems to be a misconception that Target Explorer and o.e.remote are mutually exclusive.
They are not – well definitely not for the Terminal which this discussion originated from.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development
Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
Actually I should expand on that a bit. Greg isn’t the only one working on o.e.remote. The PTP community uses it extensively for their target management. And I will be adding a CDT
remote launch that uses it (and integrated properly into the LaunchBar) to replace the RSE one. So I think we have some pretty good momentum already.
At the end of the day Eclipse Target Management is what the community decides it’s going to be. Greg has been working on org.eclipse.remote for a long time so it’s certainly not new.
I’ve thrown my hat into his ring and we’re going to work together on finishing the job. Then we can let the community decide which they like best.
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:
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.
<eclipse_launchbar_with_wr_targets.gif>_______________________________________________
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
|
