cogA set of diff/merge APIs
TypeJAR
Developed by

XWiki Development Team

Rating
Rate!
0 Votes
LicenseGNU Lesser General Public License 2.1
Bundled With

XWiki Standard

Compatibility

Since 4.1 Milestone 2

Description

Since there is no real standard API for it and that most of the existing library are not very active enough or very tied to various EDIs we decided to write our own API for XWiki ecosystem which would be independent from the actual implementation.

List Diff & Merge

Base API module

Expose generic diff and merge component implementing org.xwiki.commons.diff.DiffManager role.

The main idea of this API is that it's not tied to any type so you have to first transform the datas you want to diff into lists and the diff will be a diff between thoses two lists.

For example when you want to diff text you can choose if you want to to a line based diff, a word based diff, a character based diff, etc.

public interface DiffManager
{
    /**
     * Produce a diff between the two provided versions.
     *
     * @param <E> the type of compared elements
     * @param previous the previous version of the content to compare
     * @param next the next version of the content to compare
     * @param configuration the configuration of the diff behavior
     * @return the result of the diff
     * @throws DiffException error when executing the diff
     */
    <E> DiffResult<E> diff(List<E> previous, List<E> next, DiffConfiguration<E> configuration) throws DiffException;

    /**
     * Execute a 3-way merge on provided versions.
     * If a conflict is detected during the merge, no error is triggered and the returned {@link MergeResult} object
     * always has a result (see {@link MergeResult#getMerged()}): the conflict is automatically fixed with a fallback
     * defined by the {@link MergeConfiguration}.
     *
     * If the {@link MergeConfiguration} instance contains some {@link ConflictDecision}
     * (see {@link MergeConfiguration#setConflictDecisionList(List)}), then those decisions are taken into account
     * to solve the conflict. The decision linked to the conflict is retrieved and applied, unless the decision state
     * is still {@link org.xwiki.diff.ConflictDecision.DecisionType#UNDECIDED}. When a decision is used to solve a
     * conflict, the conflict is not recorded in the {@link MergeResult}.
     *
     * If the decision is {@link org.xwiki.diff.ConflictDecision.DecisionType#UNDECIDED}, or if no decision is available
     * for this conflict, then the fallback version defined in the {@link MergeConfiguration}
     * (see {@link MergeConfiguration#setFallbackOnConflict(MergeConfiguration.Version)}) is used to fix the conflict,
     * but in that case the conflict is recorded in the returned {@link MergeResult}.
     *
     * Finally the configuration parameter accepts a null value: in that case, the fallback version is always the
     * current version.
     *
     * @param <E> the type of compared elements
     * @param commonAncestor the common ancestor of the two versions of the content to compare
     * @param next the next version of the content to compare
     * @param current the current version of the content to compare
     * @param configuration the configuration of the merge behavior
     * @return the result of the merge
     * @throws MergeException error when executing the merge
     */
    <E> MergeResult<E> merge(List<E> commonAncestor, List<E> next, List<E> current, MergeConfiguration<E> configuration)
        throws MergeException;
}

Merge Configuration

The merge configuration class is mainly used to setup the fallback version of the merge in case of conflict. As specified in the javadoc, the merge operation always return a MergeResult which contains a merged value, even if they were conflicts during the operation. The possible fallback versions, are current, next or previous, current being the default version to fallback if nothing is specified. 

Starting with XWiki 11.7RC1 the MergeConfiguration and MergeResult classes get new APIs to retrieve precisely the conflicts information, and to be able to take decisions on a conflict by conflict basis. The decisions specified on the MergeConfiguration to solve a conflict have always the priority over the fallback configuration.

Display API module

This module helps you display a DiffResult obtained with the base API in various formats. Currently there are two diff formats supported.

Inline diff

An inline diff is made of a list of chunks, each marked as added, removed or unmodified. For instance, if changes are computed at word level, you can have this inline diff:

The quicksick brown fox jumpsstumbles over the lazycrazy mad dog.

At character level the diff looks a bit different:

the qusick brown fox

In this case the first chunk is "the ", an unmodified chunk, made of 4 characters and the second chunk is "qu", a removed chunk, made of 2 characters. An inline diff can be displayed either as you've seen above, mixing added and removed chunks in one line, or it can be displayed on two lines, one showing the removed chunks and the other the added chunks:

The quick brown fox jumps over the lazy dog.
The sick brown fox stumbles over the crazy mad dog.

Unified diff

An unified diff consists in a list of blocks, each block grouping changes that are close to each other. The distance between two changes in a block is less than 2 * context size, where context size represents the number of unmodified elements to include before and after a change in order to place that change in context.

If the elements can be split in sub-elements, i.e. if a splitter is provided through the configuration, then the unified diff displays also the changes inside the modified elements using the inline format.

If changes are computed at the line level in a text, i.e. the elements that are compared to produce the diff are lines of text, and a word splitter is provided through configuration then the following is a block from a unified diff:

@@ -81,5 +85,5 @@
 first line of context
 another unmodified line
-this line <del>has been removed</del>
+this line <ins>replaced the previous line</ins>
 close the block with unmodified lines
 last line of context

Script service

Expose more script oriented APIs of the two previous modules. It also adds helpers like String based APIs etc.

## Compute the differences between two lists of elements (e.g. lines of text).
#set ($diffResult = $services.diff.diff($previous, $next, $configuration))

## Display the differences between two texts in the unified format.
#foreach ($block in $services.diff.display.unified($previous, $next))
  $block
#end

Conflicts Display

Starting with XWiki 11.7RC1 the display diff API also allows to display information about conflicts.
The APIs to build unified diff takes as input a list of conflict elements that have been computed during a merge: some conflict information are then available in the resulting unified diff blocks, and can be used to present conflicts and possible decisions inside an UI presenting unified diff.

XML Diff

This module provides an API to compute and display the changes between 2 XML trees (DOM instances). It was introduced in XWiki 11.6RC1.

Computing the Changes

To compute the changes you need to use the XMLDiff component.

public interface XMLDiff
{
   /**
     * Computes the difference between two XML nodes and their descendants. When a text node, attribute, comment or any
     * value node type in general is modified we compute the difference at character level. Otherwise the difference is
     * expressed at node level, as if two lists of nodes are compared.Levenshtein distance
     * <p>
     * The result is a mapping between nodes from the left side and the patches that need to be applied to these nodes
     * in order for the left tree to become the right tree. If the root nodes of the left and right trees don't match
     * then this change is mapped to the {@code null} key.
     *
     * @param left the left side of the comparison
     * @param right the right side of the comparison
     * @param config the configuration
     * @return the differences between the two XML nodes
     * @throws DiffException if the difference can't be computed
     */

    Map<Node, Patch<?>> diff(Node left, Node right, XMLDiffConfiguration config) throws DiffException;
}

The default implementation uses the list diff API to compute the changes between child nodes, attributes and text content. The algorithm is quite simple:

if leftNode and rightNode are "similar"
  if leftNode has value (true for text, comment or attribute nodes)
    if leftNode's value is different than rightNode's value
      compute the changes at character level (lists of characters)
  else
    if leftNode has attributes (true for elements)
      compute the difference between attributes (added, removed, modified)
    compute the difference between child nodes (lists of nodes), matching nodes that are "very similar"
    compute (recursively) the changes between leftNode's children that are "very similar" to rightNode's children
else
  add change delta

Where "similar" and "very similar" are defined as:

similar = same nodeType, nodeName, localName, namespaceURI, prefix
very similar = similar and the percent of text changes (Levenshtein distance / max length) is less than 60%

Displaying the Changes

To display the changes you need to use the XMLDiffMarker and XMLDiffPruner components like this:

// Compute the changes and mark them in the previous document (e.g. using special attributes and elements).
if (xmlDiffMarker.markDiff(previousDocument, nextDocument)) {
 // Hide nodes that have not changed.
 xmlDiffPruner.prune(previousDocument);
 // Serialize previous document.
 ...
} else {
 // No changes detected.
}

HTML Visual Diff

Both XMLDiffMarker and XMLDiffPruner have implementations dedicated to computing a visual diff on HTML. Best is to use the provided script service:

<div class="html-diff">
  #set ($htmlDiff = $services.diff.html.unified($previousHTML, $nextHTML))
  #if ($htmlDiff == '')
    No changes.
  #elseif ("$!htmlDiff" == '')
    Failed to compute the changes.
  #else
    $htmlDiff
  #end
</div>
Tags:
Created by Thomas Mortagne on 2012/05/31 15:53
    

Get Connected