Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » IProjectDescription getLocation() x getLocationURI()
IProjectDescription getLocation() x getLocationURI() [message #298390] Mon, 30 January 2006 15:51 Go to next message
Marcelo Paternostro is currently offline Marcelo PaternostroFriend
Messages: 602
Registered: July 2009
Senior Member
Hi,

As we were trying to get rid of deprecation warnings in our code, we run
into the deprecation of IProjectDescription.getLocation(). Usually the
Eclipse javadoc is very rich, describing exactly what to do to stop
using a deprecated API. Unfortunately this is not the case.

How should one replace getLocation() by getLocationURI()? What are the
"gotchas"? Also, what is the "default location" mentioned in the
getLocationURI javadoc?

Thanks in advance,
Marcelo
Re: IProjectDescription getLocation() x getLocationURI() [message #298398 is a reply to message #298390] Mon, 30 January 2006 16:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mvalenta.ca.ibm.com

This API is new in 3.2. Your best course of action would be to log a bug
to improve the description. You can have a look at the setLocationURI()
method for a bit more information. I'll try my best to answer your
specific questions but I'm not the authority on the subject.

In 3.2, Eclipse projects can now be hosted on non-local file systems. To
support this, locations must be specified as URIs where the scheme
identifies the file system (see the org.eclipse.core.filesystem plugin).
If you previously used getLocation(), you can still use it but if a
null is returned, it may be because the project is a direct child of
your workspace directory or is stored on a non-local file system (or an
alternate file system like in a Zip file). The getLocationURI() method
returns the URI whose scheme may be "file" or something else. A null
means the project is on the local disk as a direct child of the
workspace directory. A scheme of "file" means you can access the
underlying files using java.io.File, FOr any other scheme, you would
need to use the API in org.eclipse.core.filesystem.

Michael

Marcelo Paternostro wrote:
> Hi,
>
> As we were trying to get rid of deprecation warnings in our code, we run
> into the deprecation of IProjectDescription.getLocation(). Usually the
> Eclipse javadoc is very rich, describing exactly what to do to stop
> using a deprecated API. Unfortunately this is not the case.
>
> How should one replace getLocation() by getLocationURI()? What are the
> "gotchas"? Also, what is the "default location" mentioned in the
> getLocationURI javadoc?
>
> Thanks in advance,
> Marcelo
Re: IProjectDescription getLocation() x getLocationURI() [message #298429 is a reply to message #298390] Mon, 30 January 2006 19:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: john.eclipsefaq.org

Also, see Help > Help Contents > Platform Plugin Developer Guide >
Migration Guide > Migrating to Eclipse 3.2 > Incompatibilities >
"Resources are no longer necessarily in the local file system".
--

Marcelo Paternostro wrote:
> Hi,
>
> As we were trying to get rid of deprecation warnings in our code, we run
> into the deprecation of IProjectDescription.getLocation(). Usually the
> Eclipse javadoc is very rich, describing exactly what to do to stop
> using a deprecated API. Unfortunately this is not the case.
>
> How should one replace getLocation() by getLocationURI()? What are the
> "gotchas"? Also, what is the "default location" mentioned in the
> getLocationURI javadoc?
>
> Thanks in advance,
> Marcelo
Re: IProjectDescription getLocation() x getLocationURI() [message #298528 is a reply to message #298398] Tue, 31 January 2006 16:58 Go to previous messageGo to next message
Marcelo Paternostro is currently offline Marcelo PaternostroFriend
Messages: 602
Registered: July 2009
Senior Member
Thank you for the quick answer!

Michael Valenta wrote:
> This API is new in 3.2. Your best course of action would be to log a bug
> to improve the description. You can have a look at the setLocationURI()
> method for a bit more information. I'll try my best to answer your
> specific questions but I'm not the authority on the subject.
>
> In 3.2, Eclipse projects can now be hosted on non-local file systems. To
> support this, locations must be specified as URIs where the scheme
> identifies the file system (see the org.eclipse.core.filesystem plugin).
> If you previously used getLocation(), you can still use it but if a
> null is returned, it may be because the project is a direct child of
> your workspace directory or is stored on a non-local file system (or an
> alternate file system like in a Zip file). The getLocationURI() method
> returns the URI whose scheme may be "file" or something else. A null
> means the project is on the local disk as a direct child of the
> workspace directory. A scheme of "file" means you can access the
> underlying files using java.io.File, FOr any other scheme, you would
> need to use the API in org.eclipse.core.filesystem.
>
> Michael
>
> Marcelo Paternostro wrote:
>> Hi,
>>
>> As we were trying to get rid of deprecation warnings in our code, we
>> run into the deprecation of IProjectDescription.getLocation().
>> Usually the Eclipse javadoc is very rich, describing exactly what to
>> do to stop using a deprecated API. Unfortunately this is not the case.
>>
>> How should one replace getLocation() by getLocationURI()? What are
>> the "gotchas"? Also, what is the "default location" mentioned in the
>> getLocationURI javadoc?
>>
>> Thanks in advance,
>> Marcelo
Re: IProjectDescription getLocation() x getLocationURI() [message #298529 is a reply to message #298429] Tue, 31 January 2006 16:59 Go to previous message
Marcelo Paternostro is currently offline Marcelo PaternostroFriend
Messages: 602
Registered: July 2009
Senior Member
Thank you for the tip!

John Arthorne wrote:
> Also, see Help > Help Contents > Platform Plugin Developer Guide >
> Migration Guide > Migrating to Eclipse 3.2 > Incompatibilities >
> "Resources are no longer necessarily in the local file system".
> --
>
> Marcelo Paternostro wrote:
>> Hi,
>>
>> As we were trying to get rid of deprecation warnings in our code, we
>> run into the deprecation of IProjectDescription.getLocation().
>> Usually the Eclipse javadoc is very rich, describing exactly what to
>> do to stop using a deprecated API. Unfortunately this is not the case.
>>
>> How should one replace getLocation() by getLocationURI()? What are
>> the "gotchas"? Also, what is the "default location" mentioned in the
>> getLocationURI javadoc?
>>
>> Thanks in advance,
>> Marcelo
Previous Topic:Intel-Mac builds?
Next Topic:combo box in a form
Goto Forum:
  


Current Time: Fri Apr 26 02:19:00 GMT 2024

Powered by FUDForum. Page generated in 0.03269 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top