[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] PTP/RDT and remote linuxtools
|
On 10/13/2011 09:29 PM, Corey Ashford wrote:
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?
That it shouldn't look at the nature. If one can use the filesystem
drop down to create the remote project, then there is no special wizard
needed and there is no nature requirement.
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?
Yes, I think that may be the better way to do this. The extension would
then specify which connections it supports rather than natures.
- Corey
