anchor.diff:  The Java source code can be found in the /src/main/java/org/drools/examples/sudoku directory, with the two DRL files defining the rules located in the /src/main/rules/org/drools/examples/sudoku directory.
   
   The package `org.drools.examples.sudoku.swing` contains a set of classes which implement a framework for Sudoku puzzles.
  -Note that this package does not have any dependencies on the Drools libraries. `SudokuGridModel` defines an interface which can be implemented to store a Sudoku puzzle as a 9x9 grid of `Cell` objects. `SudokuGridView` is a Swing component which can visualize any implementation of ``SudokuGridModel``. `SudokuGridEvent` and `SudokuGridListener` are used to communicate state changes between the model and the view: events are fired when a cell's value is resolved or changed.
  -If you are familiar with the model-view-controller patterns in other Swing components such as `JTable` then this pattern should be familiar. `SudokuGridSamples` provides a number of partially filled Sudoku puzzles for demonstration purposes.
  +Note that this package does not have any dependencies on the Drools libraries.
  +`SudokuGridModel` defines an interface which can be implemented to store a Sudoku puzzle as a 9x9 grid of `Cell` objects.
  +`SudokuGridView` is a Swing component which can visualize any implementation of `SudokuGridModel`.
  +`SudokuGridEvent` and `SudokuGridListener` are used to communicate state changes between the model and the view: events are fired when a cell's value is resolved or changed.
  +If you are familiar with the model-view-controller patterns in other Swing components such as `JTable` then this pattern should be familiar.
  +`SudokuGridSamples` provides a number of partially filled Sudoku puzzles for demonstration purposes.
   
  -Package `org.drools.examples.sudoku.rules` contains a utility class with a method for compiling DRL files.
  -
  -The package `org.drools.examples.sudoku` contains a set of classes implementing the elementary `Cell` object and its various aggregations: the `CellFile` subtypes `CellRow` and `CellCol` as well as ``CellSqr``, all of which are subtypes of ``CellGroup``.
  -It's interesting to note that `Cell` and `CellGroup` are subclasses of ``SetOfNine``, which provides a property `free` with the type ``Set<Integer>``.
  +The package `org.drools.examples.sudoku` contains a set of classes implementing the elementary `Cell` object and its various aggregations: the `CellFile` subtypes `CellRow` and `CellCol` as well as `CellSqr`, all of which are subtypes of `CellGroup`.
  +It's interesting to note that `Cell` and `CellGroup` are subclasses of `SetOfNine`, which provides a property `free` with the type `Set<Integer>`.
   For a `Cell` it represents the individual candidate set; for a `CellGroup` the set is the union of all candidate sets of its cells, or, simply, the set of digits that still need to be allocated.
   
  -With 81 `Cell` and 27 `CellGroup` objects and the linkage provided by the `Cell` properties  ``cellRow``, `cellCol` and `cellSqr` and the `CellGroup` property ``cells``, a list of `Cell` objects, it is possible to write rules that detect the specific situations that permit the allocation of a value to a cell or the elimination of a value from some candidate  set.
  +With 81 `Cell` and 27 `CellGroup` objects and the linkage provided by the `Cell` properties `cellRow`, `cellCol` and `cellSqr` and the `CellGroup` property `cells`, a list of `Cell` objects, it is possible to write rules that detect the specific situations that permit the allocation of a value to a cell or the elimination of a value from some candidate set.
   
  -An object of class `Setting` is used for triggering the operations that accompany the allocation of a value: its removal from the candidate sets of sibling cells and associated cell groups.
  +An object of class `Setting` is used for triggering the operations that accompany the allocation of a value.
   Moreover, the presence of a `Setting` fact is used in all rules that should detect a new situation; this is to avoid reactions to inconsistent intermediary states.
   
   An object of class `Stepping` is used in a low priority rule to execute an emergency halt when a "Step" does not terminate regularly.
  
positive.code: = Sudoku Example
  
  [source]
  ----
  
negative.code: Row 8:    34       --- 9 ---     4 6 8   --- 7 ---  --- 1 ---   23456 8     3 56 8     3 56          6 8
  ----
  
  Now, let us load a Sudoku grid that is deliberately invalid. Click on "File", "Samples" and "!DELIBERATELY BROKEN!".
  Note that this grid starts with some issues, for example the value 5 appears twice in the first row.
  
  .Broken initial state
  image::Examples/SudokuExample/sudoku4.png[align="center"]
  
  Nevertheless, click on the "Solve" button to apply the solving rules to this invalid grid.
  This will not complete; some cells remain empty.
  
  There are a few simple rules that perform a sanity check.
  In this case, the following messages are printed on standard output:
  
  ----
  cell [0,8]: 5 has a duplicate in row 0
  cell [0,0]: 5 has a duplicate in row 0
  cell [6,0]: 8 has a duplicate in col 0
  cell [4,0]: 8 has a duplicate in col 0
  Validation complete.
  ----
  
  .Broken "solved" state
  image::Examples/SudokuExample/sudoku5.png[align="center"]
  