|
Re: IProjectDescription getLocation() x getLocationURI() [message #298398 is a reply to message #298390] |
Mon, 30 January 2006 16:13 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 |
Marcelo Paternostro 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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03269 seconds