Responding to resource changes in the eclipse Workspace

Administrative Tools and user interface elements are interested in processing resource changes as they happen. for example, the task list wants to update new or changed markers, the navigator wants to reflect added and deleted resources, and the Java compiler wants to recompile modified java files. such events are potentially costly to compute, manage and broadcast. the eclipse platform resource model provided des a series of mechanisms for efficiently policying clients of resource changes. this article outlines these facilities and gives some examples of their use.

Resource Change listeners A good listener is not only popular everywhere,
But after a while, he knows something.
-Wilson Mizner

The primary method for Eclipse plug-ins to be notified of changes to resources is by installingResource Change listener. These listeners are given after-the-fact notification of what projects, folders and files changed during the last resource changing operation. this provides a powerful mechanic for plug-ins to keep their domain state synchronized with the state of the underlying workspace. since listeners are told exactly what resources changed (and how they changed), they can update their model incrementally, which ensures that the time taken by the update is proportional to the size of the change, not the size of the workspace.

Listeners must implementIResourceChangeListenerInterface, and are registered using the methodaddResourceChangeListenerOnIWorkspace. It is also important to remove your Resource Change listener when it is no longer needed, usingIWorkspace.removeResourceChangeListener.

During a resource change notification, the workspace is locked to prevent further modification while the changes are happening. this is necessary to ensure that all listeners are notified of all workspace changes. otherwise, a change made by one listener wocould have to be broadcast to all other listeners, easily creating the possibility of an infinite loop. there is a special exception to this rule forPRE_AUTO_BUILDAndPOST_AUTO_BUILDEvent types that will be discussed later on.

Before we get into the details, let's start with a simple example that shows how to add and remove a Resource Change listener:

   IWorkspace workspace = ResourcesPlugin.getWorkspace();   IResourceChangeListener listener = new IResourceChangeListener() {      public void resourceChanged(IResourceChangeEvent event) {         System.out.println("Something changed!");      }   };   workspace.addResourceChangeListener(listener);   //... some time later one ...   workspace.removeResourceChangeListener(listener);

 Below is an example of an operation that is nested using the IWorkspaceRunnable mechanism. In this case, a single resource change event will be broadcast, indicating that one project and ten files have been created. To keep it simple, progress monitoring and exception handling have been omitted from this example. 
   IWorkspace workspace = ResourcesPlugin.getWorkspace();   final IProject project = workspace.getRoot().getProject("My Project");   IWorkspaceRunnable operation = new IWorkspaceRunnable() {      public void run(IProgressMonitor monitor) throws CoreException {         int fileCount = 10;         project.create(null);         project.open(null);         for (int i = 0; i < fileCount; i++) {            IFile file = project.getFile("File" + i);            file.create(null, IResource.NONE, null);         }      }   };   workspace.run(operation, null);
details please visit http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html