| Problems with the api for deleting a folder? [message #313595] |
Tue, 20 March 2007 14:31  |
Eclipse User |
|
|
|
Originally posted by: kmm.sdddddddfj.com
Hi all,
Thanks for helping me.
In one of my tests I am trying to programmaticaly delete a folder. This is
the method I use:
protected void deleteEarDirectory() throws InterruptedException {
final IFolder earFolder = getEarFolder();
WorkspaceJob deleteEarJob = new WorkspaceJob("Delete Ear directory") {
@Override
public IStatus runInWorkspace(IProgressMonitor monitor) throws
CoreException {
try {
monitor.beginTask("Delete ear directory", 100);
assertNotNull(earFolder);
if (earFolder.exists()) {
earFolder.delete(true, false, new SubProgressMonitor(monitor,
80));
}
assertFalse(earFolder.exists());
ResourcesPlugin.getWorkspace().getRoot().refreshLocal(IResou rce.DEPTH_INFINITE,
new SubProgressMonitor(monitor, 20));
} finally {
monitor.done();
}
return Status.OK_STATUS;
}
};
deleteEarJob.setRule(ResourcesPlugin.getWorkspace().getRoot( ));
deleteEarJob.setPriority(Job.LONG);
deleteEarJob.schedule();
deleteEarJob.join();
assertFalse(earFolder.exists());
}
The problem is that the final assert does not pass. Even more - if I run
the test in a debug mode the test now pass. Does anybody has a idea why
this method does not work?
The earForlder is just a normal folder in a project. It should be
mentioned that this folder might not be empty - it might contain files.
With the delete method the files should also be deleted. Is it possible
for this to cause the problems?
Thank you for the help,
Best regard,
Kiril Mitov
|
|
|
| Re: Problems with the api for deleting a folder? [message #313603 is a reply to message #313595] |
Tue, 20 March 2007 14:58  |
| Eclipse User |
|
|
|
Originally posted by: dmsubs.NOSPAM.consertum.com
My guess is that the delete is done as a background task - in a separate thread
to the one you are running in. Therefore, when you try the assert in 'run' mode,
it hasn't finished the delete, but when you run in debug, it will have completed
the delete.
So, why do you need the assert - don't you trust it?
--
Derek
kiril mitov wrote:
> Hi all, Thanks for helping me.
> In one of my tests I am trying to programmaticaly delete a folder. This
> is the method I use:
>
> protected void deleteEarDirectory() throws InterruptedException {
> final IFolder earFolder = getEarFolder();
> WorkspaceJob deleteEarJob = new WorkspaceJob("Delete Ear directory") {
> @Override
> public IStatus runInWorkspace(IProgressMonitor monitor) throws
> CoreException {
> try {
> monitor.beginTask("Delete ear directory", 100);
> assertNotNull(earFolder);
> if (earFolder.exists()) {
> earFolder.delete(true, false, new SubProgressMonitor(monitor,
> 80));
> }
> assertFalse(earFolder.exists());
>
> ResourcesPlugin.getWorkspace().getRoot().refreshLocal(IResou rce.DEPTH_INFINITE,
> new SubProgressMonitor(monitor, 20));
> } finally {
> monitor.done();
> }
> return Status.OK_STATUS;
> }
> };
> deleteEarJob.setRule(ResourcesPlugin.getWorkspace().getRoot( ));
> deleteEarJob.setPriority(Job.LONG);
> deleteEarJob.schedule();
> deleteEarJob.join();
> assertFalse(earFolder.exists());
> }
>
> The problem is that the final assert does not pass. Even more - if I run
> the test in a debug mode the test now pass. Does anybody has a idea why
> this method does not work?
> The earForlder is just a normal folder in a project. It should be
> mentioned that this folder might not be empty - it might contain files.
> With the delete method the files should also be deleted. Is it possible
> for this to cause the problems?
>
> Thank you for the help,
>
> Best regard, Kiril Mitov
>
|
|
|
| Re: Problems with the api for deleting a folder? [message #313606 is a reply to message #313603] |
Tue, 20 March 2007 15:37 |
| Eclipse User |
|
|
|
Originally posted by: kmm.sdddddddfj.com
Thanks for the answer.
I also thought that there is a thread problem, but I am invoking
deleteEarJob.join() and according to the javadoc of this method - the
method should block the current thread until the job is over. And when the
job is over the folder should be deleted.
Basically I do not "believe" the IFolder.delete because I have run into
several problems with overlapping content in the earFolder. So I prefer to
assert that the folder is deleted before and after every test in my test
case.
I am sure that IFolder.delete is working, but it seems I just do not
understand how to use it properly. Isn`t it true that after IFolder.delete
is executed than IResource.exists() should return false?
Regards,
Kiril
Derek Morris wrote:
> My guess is that the delete is done as a background task - in a separate
thread
> to the one you are running in. Therefore, when you try the assert in 'run'
mode,
> it hasn't finished the delete, but when you run in debug, it will have
completed
> the delete.
> So, why do you need the assert - don't you trust it?
|
|
|
| Re: Problems with the api for deleting a folder? [message #313612 is a reply to message #313606] |
Tue, 20 March 2007 16:18 |
| Eclipse User |
|
|
|
Originally posted by: dmsubs.NOSPAM.consertum.com
The join operates on the deleteEarJob, but the Folder.delete is going to run in
yet another thread. So, your are waiting for the deleteEarJob to complete, but
that is NOT waiting for the delete to complete. I don't know how (or if) you can
wait for the delete() to complete.
My suggestion would be to trust that delete() works and look elsewhere for your
error.
p.s. another idea would be to set up a resourcechangelistener and look for the
delete event.
--
Derek
kiril mitov wrote:
> Thanks for the answer.
>
> I also thought that there is a thread problem, but I am invoking
> deleteEarJob.join() and according to the javadoc of this method - the
> method should block the current thread until the job is over. And when
> the job is over the folder should be deleted.
>
> Basically I do not "believe" the IFolder.delete because I have run into
> several problems with overlapping content in the earFolder. So I prefer
> to assert that the folder is deleted before and after every test in my
> test case.
> I am sure that IFolder.delete is working, but it seems I just do not
> understand how to use it properly. Isn`t it true that after
> IFolder.delete is executed than IResource.exists() should return false?
>
> Regards, Kiril
> Derek Morris wrote:
>
>> My guess is that the delete is done as a background task - in a separate
> thread
>> to the one you are running in. Therefore, when you try the assert in
>> 'run'
> mode,
>> it hasn't finished the delete, but when you run in debug, it will have
> completed
>> the delete.
>
>> So, why do you need the assert - don't you trust it?
>
>
|
|
|
| Re: Problems with the api for deleting a folder? [message #313637 is a reply to message #313612] |
Wed, 21 March 2007 10:16 |
| Eclipse User |
|
|
|
Originally posted by: kmm.sdddddddfj.com
Thanks Derek,
The good old way to make a test pass is just to remove the assert - and
this is what I did. I just removed the assertFalse(folder.exists()).
But isn`t it quite strange to be unable to do a synchronous delete of a
resource. I really think I am not the first to get to this problem. The
idea with the resource change listener does not work either because the
code became to complex with to much logic to be included in the test so I
decided that it is not worth finishing it.
What I was able to notice is that the tests do not pass only when the
folder is not empty. But even then they are not failing in a stable
manner...
However,
thank you for the replies. They were of big help to me.
Regards,
Kiril
Derek Morris wrote:
> The join operates on the deleteEarJob, but the Folder.delete is going to run
in
> yet another thread. So, your are waiting for the deleteEarJob to complete,
but
> that is NOT waiting for the delete to complete. I don't know how (or if) you
can
> wait for the delete() to complete.
> My suggestion would be to trust that delete() works and look elsewhere for
your
> error.
> p.s. another idea would be to set up a resourcechangelistener and look for
the
> delete event.
|
|
|
Powered by
FUDForum. Page generated in 0.03229 seconds
] 
Search
Help
Register
Login
Home
