Re: [linuxtools-dev] PTP/RDT and remote linuxtools

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 10/13/2011 12:25 PM, Jeff Johnston wrote:
> On 10/13/2011 02:15 PM, Jeff Johnston wrote:
>> On 10/12/2011 09:29 PM, Corey Ashford wrote:
>>> On 10/12/2011 05:56 PM, Corey Ashford wrote:
>>>> On 10/11/2011 12:48 PM, Jeff Johnston wrote:
>>>>> Just to let people know that I have updated the RDT branch with the
>>>>> extension and plug-in necessary to allow RDT to be optionally
>>>>> connected
>>>>> with Autotools.
>>>>>
>>>>> The extension lists the nature id it supports so in theory, we could
>>>>> support alternates to RDT some day if desired.
>>>>>
>>>>> The shared code checks the project nature and at the moment just looks
>>>>> for the RDT remote nature. If not found, it uses local proxies for
>>>>> file
>>>>> access, launching, and the platform OS. If the RDT nature is found, it
>>>>> looks for the extension that supports the RDT nature and then gets a
>>>>> factory which returns the proxies for file access, launching, and
>>>>> retrieving the platform OS (needed in the case of Windows support).
>>>>>
>>>>> I'd appreciate any comments folks have on this branch.
>>>>>
>>>>> I tend to like it because RDT is optional. We are free to support
>>>>> other
>>>>> forms or multiple forms of remote project strategy if desired.
>>>>>
>>>>> I also have a branch whereby I have direct RDT calls in Autotools. If
>>>>> people are interested, I can make that branch public as well.
>>>>>
>>>>> -- Jeff J.
>>>>
>>>> Jeff, I just tried building your rdt branch and am getting one
>>>> compilation error that I don't know how to resolve:
>>>>
>>>> Name clash: The method getAdapter(Class<?>) of type IAutotoolsEditor
>>>> has
>>>> the same erasure as getAdapter(Class) of type IAdaptable but does not
>>>> override it IAutotoolsEditor.java
>>>> /org.eclipse.linuxtools.cdt.autotools.ui/src/org/eclipse/linuxtools/cdt/autotools/ui/editors
>>>>
>>>>
>>>> line 9 Java Problem
>>>>
>>>> Any ideas? I'm using the IBM Java compiler, so maybe the OpenJDK
>>>> doesn't complain about this?
>>>>
>>>
>>> I commented out this line and it compiled. However, I'm a bit confused
>>> as to how to test out your new code.
>>>
> 
> Not sure why I don't see an error.  Removing the line is fine because
> the method is already part of the interfaces being extended.  I will
> remove it from the branch.
> 
>>> I created a new C project (not Remote C/C++ project, because that
>>> doesn't have any autotools toolchains I can select) and selected the GNU
>>> Autotools Toolchain.
>>>
>>> I selected Remote Tools as the filesystem provider, and a valid remote
>>> directory and connection. It created all of the files for the example
>>> Hello World ANSI C Autotools Project. When I go to build it, I get this
>>> NPE:
>>>
> 
>>>
>>> Have you seen this?
>>
>> No, but I know what is causing it. I am trying to get the Project's
>> location and add a path to it, then using the proxy File Manager to do a
>> getResource().
>>
>> The getLocation() call tries to return an IPath or null. I should be
>> using getLocationURI() instead. I am looking into it. I will have to
>> change this in a number of places.
>>
> 
> I performed a similar experiment to yours whereby I chose RSE as my
> filesystem and picked a localhost location for the new project.
> 
> I got the following sequence in getSavedConfigs() to work for both a
> regular local project and an RSE filesystem (localhost) project:
> 
> URI projectLocation = project.getLocationURI();
> URI fileLocation = new URI(projectLocation.toString() + "/" +
>     CFG_FILE_NAME); // $NON-NLS-1$
> IRemoteFileProxy proxy =
> RemoteProxyManager.getInstance().getFileProxy(project);
> IFileStore f = proxy.getResource(proxy.toPath(fileLocation).toString());
> 
> I believe this would also work for a remote RDT project.  Please correct
> me if I wrong in this assumption.

Yes, it seems like it should.

> 
> The experiment indicates to me that the proxy cannot base itself on the
> project nature.  It appears that the remote proxy should be used, if
> present, for all accesses.
> 
> Seem reasonable?

Sorry, I don't understand what you mean.  Are you saying the
getFileProxy(IProject project) method needs to be re-written not to base
on the proxy?  Or that the per-nature extension shouldn't look at the
nature?

I think the URI string already has service name (e.g. remote tools)
already encoded into it, so maybe you could use that instead of the
nature to determine which connection service to use?

- Corey