TM seems a natural fit. It would also expand TM beyond a terminal emulator which is all it seems to be right now.
I think the time has also come to bite the bullet and try to get the TM + remote issue resolved. It seems pretty silly to have TM/Terminal provide its own remote adaptors as well as a whole other set of remote adapters provided by o.e.remote.
From what I can see, the main piece that was missing from o.e.remote was a telnet adapter, which I now have in my workspace. I will commit this once I’ve updated it with the latest changes from TM, at which point I think we should start the discussion about
moving o.e.remote to TM and switching TM/Terminal to use o.e.remote exclusively.
Hey gang, it’s probably time to start dealing with some of the “misplaced” components that are in projects where they probably don’t match the mandate. The best example was actually done by me and that’s the Launch Bar. It’s a more general UI
component that leverages platform debug and launch configuration along with org.eclipse.remote’s IRemoteConnection to initiate launches on connections (Local being one of the connections).
Right now, I put it with the CDT project because I’m not sure where it really belongs and I had commit rights there. But really it should go somewhere where the community can have a better time finding it and getting involved with contributions
Any suggestions for what we should do with it? We’ve talked in the past about an IDE commons project and Greg and I have figured out a plan for that but it can’t just be the two of us so my worry about sustainability of the idea is getting worse.
I had thoughts of putting it in TM which is also where org.eclipse.remote should go though that may be like putting the two Subversion projects together (for those who’ve been around long enough to remember that episode).
tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit