Skip to main content

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

I’ll try to provide more information below:

On 2014-12-09, 6:39 AM, "Rob Stryker" <rstryker@xxxxxxxxxx> wrote:

>
>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.

The o.e.remote code is in it’s own repository. It has no dependencies on
CDT or on the rest of PTP. It is one of the candidates to help start the
IDE commons project though I still think it’s better hosted here in the TM
project. Same with the TCF Terminal work.

>
>      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.

The Remote Development -> Connections page is actually coming from
o.e.remote. I’m not sure what you point is here. It has nothing to do with
RSE. And o.e.remote has nothing to do with PTP.

>
>      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?

The o.e.remote interfaces have what we need. I am doing a slight
restructuring to those to make it easier to add services using IAdaptable.
Any functionality missing that’s in RSE and TCF will be copied over and
plugged in where needed.

>
>      4) What were the primary goals that org.eclipse.remote were trying
>to solve, that was not solvable in RSE?

Reducing the number of target management systems we have at Eclipse. IMHO,
selecting RSE for the Eclipse Target Management system was a big mistake.
There were alternatives on the table and, as I discovered recently, even
we at QNX had one that could have been contributed that we still use to
this day. And o.e.remote and TCF are alternatives available now at Eclipse
that arose because RSE didn’t meet their needs.

>
>      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?

I’m not sure the plan is to remove it at the moment. But it does need a
new set of committers to manage it and to keep it from being archived.

>
>     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?

I’ve tried to use RSE in the past for other purposes years ago. It was
such a bad experience it has caused a big negative bias for me. I have no
interest in taking a look at it again.

>
>
>    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?

As mentioned above. RSE needs a new set of committers.

>
>
>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.

Those statements seem like you haven’t actually looked at o.e.remote. Or
the proposal I am working on which I just posted last night, which makes
sense. It’s now available up at github here:

    https://github.com/dschaefer/org.eclipse.remote-api2


The proposed new API layer which cleans up the existing IRemoteConnection
interface and makes it easy to add services is in the
org.eclipse.remote.core bundle in the org.eclipse.remote.core.api2 package.

>
>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.

That’s my point. RSE isn’t a good API. And UX is horrendous. O.e.remote is
a good simple API, especially with the quick changes I made to it, and I’m
making the UX easy for new users to use.

Eclipse has always been about choice. Feel free to become a committer for
RSE and use it as you please. I’m throwing my investment into the
o.e.remote ring.

Doug

>
>- 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.Oberhu
>>>>>>>>>>>be
>>>>>>>>>>> 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>[mailt
>>>>>>>>>>>o:
>>>>>>>>>>> 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>[mailt
>>>>>>>>>>>o:
>>>>>>>>>>> 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>[mailt
>>>>>>>>>>>o:
>>>>>>>>>>> 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_r
>>>>>>>>>>>R
>>>>>>>>>>> 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_rRDps
>>>>>>>>>>>x
>>>>>>>>>>> 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_rRDp
>>>>>>>>>>>s
>>>>>>>>>>> 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
>
>_______________________________________________
>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