Responding to resource changes in the Eclipse workspace

Many 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 notifications are potentially costly to compute, manage and broadcast. The Eclipse Platform resource model includes a series of mechanisms for efficiently notifying 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 installing a resource 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 mechanism 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 implement the IResourceChangeListener interface, and are registered using the method addResourceChangeListener on IWorkspace. It is also important to remove your resource change listener when it is no longer needed, using IWorkspace.removeResourceChangeListener.

During a resource change notification, the workspace is locked to prevent further modification while the notifications are happening. This is necessary to ensure that all listeners are notified of all workspace changes. Otherwise, a change made by one listener would have to be broadcast to all other listeners, easily creating the possibility of an infinite loop. There is a special exception to this rule for the PRE_AUTO_BUILD and POST_AUTO_BUILD event 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