Receipe of the day: gradle with eclipse config.

I use Eclipse STS (Spring Tools Suite) with Spring support. To help editing gradle.build file two plugins should be installed:

• Groovy eclipse plugin http://groovy.codehaus.org/Eclipse+Plugin
• SpringSource Tool Suite Gradle Integration (is included into STS)

To generate eclipse project file from build coniguration add following to build.gradle:

apply plugin: 'eclipse' 
eclipse {    
  project {
    natures 'com.springsource.sts.gradle.core.nature',
            'org.eclipse.jdt.groovy.core.groovyNature',
            'com.springsource.sts.gradle.core.nature'
  }            
}

Showing dependency cycle in Eclipse.

Here is tiny plug-in that gathers complete build path dependency tree of a Java project in Eclipse. Eclipse tells only that there is some build path cycle but does not tell which projects are involved. If your workspace is crowded this could be a problem. The plugin allows to automatically find out cycles in project dependencies.

Again about jobs and workspace resources

There is one more caveat about resources manipulation in Eclipse's workspace. Scheduling a job with a resource scheduling rule helps to avoid unwanted intersections between different tasks. Say one job wants to modify some resource but other wants ro read some consistent state or modify same resoruce. This has two problems. First, there is no robust way to ensure jobs order, and second there is chance of lockups when using jobs for resource manipulation.

It turned out that this does not play well if your job is scheduled as part of bigger transaction. Say, Eclipse started some rename refactoring, your hob invoked as part of "save resources" procedure and wants to modify things so resources are consistent with saved editor state. And then you get into deadlock. Refactoring locked your resource for modifications, your job want to lock it for modifications too and there's no way to tell that your job is "nested" transaction. Oops.

Scheduling one job after other is tricky too. Even Eclipse's code waits for build completion before launch by polling job manager to ensure that there are no active jobs that tagged as "build job".

I found that in most cases (if your requirements are simple) better approach to modifying resources in Eclipse's workspace is to consistently use IResource's (IFile, IFolder, IProject) methods throughout your code instead of using plain java.io package. This would ensure that Eclipse is aware of your changes and you do not need to refresh resources after every modification to make Eclipse aware of it.

How to refresh resources in Eclipse's workspace

Since we add own file system implementation to EFS there's need to refresh different resources in workspace to provide better feedback to user.

Naive usage of IResource.refreshLocal(Monitor) caused cryptic exceptions a about conflicting rules. This for example happens when you first start refreshing a file and while it is processed you request to refresh it's folder. It took some time and several re-opened bugs in project I am working to figure out proper way to do refreshes. The fact that IResource also implements ISchedulingRule also adds to confusion. First problem-less implementation used Workspace.getRefreshManager().refresh(resource). Refresh manager maintains queue for refresh requests that run consequently so they do not conflict. Unfortunately Workspace is not part of public API so it lead me to look for other solutions. Parameter "monitor" in IResource.refreshLocal() lead me to inspect Job class that is used for long running background tasks. It turned out that Job has method Job.setRule(ISchedulingRule). So I created a job and set resource being refreshed as scheduling rule, this still caused refresh conflicts. So finally working code looks like this:

public static void refresh(final IResource resource) {
        final Job job = new Job("Refreshing " + resource) {
            @Override
            protected IStatus run(final IProgressMonitor monitor) {
                try {
                    resource.refreshLocal(IResource.DEPTH_INFINITE, monitor);
                    return new Status(IStatus.OK, "my.shiny.plugin", "Refreshed " + resource);
                } catch (final CoreException e) {
                    return new Status(IStatus.ERROR, "my.shiny.plugin", "Error refreshing "
                            + resource, e);
                }
            }
        };
        job.setRule(ResourcesPlugin.getWorkspace().getRuleFactory().refreshRule(resource));
        job.schedule();
    }

Last tar pit you might step into is names of rule factory. "createRule" returns rule for resource creation operation (although it worked in my case). The method that returns rule for refresh is "refreshRule".