The following piece of code is the simplest check you could possibly write:

package org.openarchitectureware.recipe.checks.test; 

import org.openarchitectureware.recipe.core.AtomicCheck; 
import org.openarchitectureware.recipe.eval.EvaluationContext; 

public class HelloWorldCheck extends AtomicCheck { 
  private static final long serialVersionUID = 1L; 
  public HelloWorldCheck() { 
    super( "hello world", "this check always succeeds" ); 
  }
  
  public void evaluate(EvaluationContext c) { 
    ok(); 
  } 
}

A couple of notes:

More sensible checks distinguish themselves in two respects:

An example:

public void evaluate(EvaluationContext c) { 
   if ( something is not right ) { 
      fail( "something has gone wrong"); 
   } 
   if ( some condition is met ) { 
      ok(); 
   }

By the way, you don’t need to care about the EvaluationContext. Its only needed by the framework.

Eclipse checks are a bit special. If the check were implemented in the way described above, you’d have a lot of dependencies to all the Eclipse plugins/jars. You’d have these dependencies as soon as you’d instantiate the check – i.e. also in the generator when you configure the check. In order to avoid this, we have to decouple the configuration of a check in the generator and its evaluation later in Eclipse:

An Eclipse check is thus implemented in the following way. First of all, our check has to extend the EclipseCheck base class.

public class ResourceExistenceCheck extends EclipseCheck {

Again, we add a serial version uid to make sure deserialization will work.

private static final long serialVersionUID = 2L; 

In the constructor we decide whether we want to have this check evaluated whenever the Eclipse workspace changes (EvalTrigger.ON_CHANGE) or not. We also store some of the parameters in the parameter facility of the framework. Note that we do no implement the evaluate() operation!

   public ResourceExistenceCheck( String message, 
          String projectName, String resourceName ) { 
      super( "resource exists exists", message, EvalTrigger.ON_CHANGE ); 
      setProjectName( projectName ); 
      setResourceName( resourceName ); 
   } 
  
   private void setProjectName(String projectName) { 
      setParameter( "projectName", projectName ); 
   } 
  
   private void setResourceName(String resourceName) { 
      setParameter( "resourceName", resourceName ); 
   }

In order to provide the evaluation functionality, you have to implement an ICheckEvaluator. It has to have the same qualified name as the Check itself, postfixed with Evaluator. During the evaluation of the check, the class is loaded dynamically based on its name. A wrong name will result in a runtime error during evaluation the Eclipse Plugin.

public class ResourceExistenceCheckEvaluator 
implements ICheckEvaluator { 

public void evaluate( AtomicCheck check ) { 
   String projectName = 
       check.getParameter("projectName").getValue().toString(); 
   String resourceName = 
      check.getParameter("resourceName").getValue().toString(); 
   IWorkspace workspace = ResourcesPlugin.getWorkspace(); 
   IResource project = 
        workspace.getRoot().getProject(projectName); 
   if ( project == null ) 
      check.fail("project not found: "+projectName); 
   IFile f = workspace.getRoot().getFile( 
      new Path(projectName+"/"+resourceName) ); 
   String n = f.getLocation().toOSString(); 
   if ( !f.exists() ) check.fail( 
      "resource not found: "+projectName+"/"+resourceName); 
      check.ok();} 

When implementing the evaluator, you can basically do the same things as in the evaluate() operation in normal checks. However, in order to set the ok() or fail(“why”) flags, you have to call the respective operations on the check passed as the parameter to the operation.

In order to allow the Eclipse runtime to execute your checks, it has to find the respective classes when deserializing the recipe file. This is a bit tricky in Eclipse, since each plugin has its own classloader. So assume you want to define your own checks and want to use them in Eclipse; what you have to do is: implement your own plugin that extends a given extension point in the Recipe Browser plugin. The following XML is the plugin descriptor of the org.openarchitectureware.recipe.eclipseChecks.plugin.EclipseChecksPlugin, a sample plugin that comes with the recipe framework and provides a number of Eclipse-capable checks.

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
   id="org.openarchitectureware.recipe.eclipseChecks"
   name="%plugin_name"
   version="4.0.0"
   provider-name="%provider_name"
   class="org.openarchitectureware.recipe.\
   eclipseChecks.plugin.EclipseChecksPlugin">

Here we now define the jar file that contains our checks (will be important below!)

   <runtime>
      <library name="oaw-recipe-eclipsechecks.jar">
         <export name="*"/>
      </library>
   </runtime>

The required plugins mainly depend on the implementations of the CheckEvaluators, of course, however, you have to make sure the dependencies contains the org.openarchitectureware.recipe plugin, since you’re going to extend an extension point defined therein.

   <requires>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.core.runtime"/>
      <import plugin="org.eclipse.core.resources"/>
      <import plugin="org.openarchitectureware.recipe"/>
      <import plugin="org.eclipse.jdt.core"/>
   </requires>

This is the important line: here you specify that you extend the check extension point of the Recipe Browser Plugin. If you don’t do this, deserialization of the recipe file will fail and you’ll get nasty errors. And yes, you need the dummy element; otherwise the class loading "magic" will not work.

   <extension point="org.openarchitectureware.recipe.check”>
      <dummy/>
   </extension>
</plugin>

When you need to use the checks outside of Eclipse (e.g. in the generator for configuration/serialization purposes) you just add the plugin’s jar to your generator classpath. You don’t need all the Eclipse plugin’s jars referenced in the requires section, since these things will only be used during evaluation!