| project.getWorkingLocation() [message #328079] |
Tue, 13 May 2008 14:48  |
Eclipse User |
|
|
|
Dear all,
I was playing with the project.getWorkingLocation() method but I have
issues. Could anyone tell me why the following code causes an exception?
IProject test =
ResourcesPlugin.getWorkspace().getRoot().getProject("test");
if (!test.exists()) {
test.create(null);
}
IPath workingLocation = test.getWorkingLocation(Activator.PLUGIN_ID);
System.out.format("Working location: %s\n", workingLocation);
IPath folderPath = workingLocation.append("folder");
System.out.format("Folder: %s\n", folderPath);
IFolder folder =
ResourcesPlugin.getWorkspace().getRoot().getFolder(folderPat h);
if(!folder.exists()) {
folder.create(true, true, null);
}
The output is:
Working location:
/.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.co re.resources/.projects/test/test.resources
Folder:
/.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.co re.resources/.projects/test/test.resources/folder
org.eclipse.core.internal.resources.ResourceException: Resource
'/.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.c ore.resources/.projects/test/test.resources'
does not exist.
Of course if I do a "cd
/.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.co re.resources/.projects/test/test.resources "
the directory is there.
This brings two questions:
1) Maybe the working location should be used through standard java.io
mechanisms?
2) Is the working location a good location for storing some frequently
recomputed information such as cache indexes, temp files, etc.? In my
application I don't want to flood listeners with resource change events
for data that is never used directly and that should not be accessible
from the project.
Thank you for your hints.
Cheers,
Fabio
|
|
|
| Re: project.getWorkingLocation() [message #328089 is a reply to message #328079] |
Tue, 13 May 2008 16:18  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Fabio,
Comments below.
Fabio Mancinelli wrote:
> Dear all,
>
> I was playing with the project.getWorkingLocation() method but I have
> issues. Could anyone tell me why the following code causes an exception?
>
> IProject test =
> ResourcesPlugin.getWorkspace().getRoot().getProject("test");
> if (!test.exists()) {
> test.create(null);
> }
So you create a project test.
>
> IPath workingLocation = test.getWorkingLocation(Activator.PLUGIN_ID);
> System.out.format("Working location: %s\n", workingLocation);
And then get a working location for it...
>
> IPath folderPath = workingLocation.append("folder");
> System.out.format("Folder: %s\n", folderPath);
Then you make a path under that working location.
>
> IFolder folder =
> ResourcesPlugin.getWorkspace().getRoot().getFolder(folderPat h);
This looks bad. The working location isn't in the workspace. Keep in
mind that the paths used in these kinds of methods are workspace
relative, i.e., /project/path, not absolute file system paths.
> if(!folder.exists()) {
> folder.create(true, true, null);
> }
>
> The output is:
>
> Working location:
> /.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.co re.resources/.projects/test/test.resources
>
>
> Folder:
> /.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.co re.resources/.projects/test/test.resources/folder
>
>
> org.eclipse.core.internal.resources.ResourceException: Resource
> '/.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.c ore.resources/.projects/test/test.resources'
> does not exist.
It's pointing out that there is no IFolder that's a parent of the folder
you're trying to create.
>
> Of course if I do a "cd
> /.../runtime-ResourcesTest/.metadata/.plugins/org.eclipse.co re.resources/.projects/test/test.resources "
> the directory is there.
>
> This brings two questions:
>
> 1) Maybe the working location should be used through standard java.io
> mechanisms?
Yes.
>
> 2) Is the working location a good location for storing some frequently
> recomputed information such as cache indexes, temp files, etc.? In my
> application I don't want to flood listeners with resource change
> events for data that is never used directly and that should not be
> accessible from the project.
Hmmm. Good question. I suspect that it is good for that, but my
comment isn't well informed.
>
> Thank you for your hints.
>
> Cheers,
> Fabio
|
|
|
| Re: project.getWorkingLocation() [message #328093 is a reply to message #328089] |
Tue, 13 May 2008 17:01 |
| Eclipse User |
|
|
|
Ed Merks wrote:
> This looks bad. The working location isn't in the workspace. Keep in
> mind that the paths used in these kinds of methods are workspace
> relative, i.e., /project/path, not absolute file system paths.
....
>> This brings two questions:
>>
>> 1) Maybe the working location should be used through standard java.io
>> mechanisms?
> Yes.
>
What confused me is that the getWorkingLocation() is in the Workspace
API but the result it provides is not good to be used with workspace
mechanisms.
>> 2) Is the working location a good location for storing some frequently
>> recomputed information such as cache indexes, temp files, etc.? In my
>> application I don't want to flood listeners with resource change
>> events for data that is never used directly and that should not be
>> accessible from the project.
> Hmmm. Good question. I suspect that it is good for that, but my
> comment isn't well informed.
Plugins are using the OSGi getStateLocation() for getting their working
off-workspace directory. getWorkingLocation() is basically using the
same function for returning the location. So as you hinted I think as
well that this is the correct way to store project-related side-information.
Thank you again.
Cheers,
Fabio
|
|
|
Powered by
FUDForum. Page generated in 0.03776 seconds
Home