1.2 M3

Transaction: Support for Open Composite Operations

The Workspace Integration layer's IOperationHistory-based CommandStack implementation now supports open composite operations. Now, a
CompositeEMFOperation can safely implement the
ICompositeOperation interface to be "opened" on the history while other operations are executed within its scope. The editing domain will correctly attach
ResourceUndoContexts to the composite when it completes, ensuring that it appears on the Undo menu of any editor on the affected Resources.

This works also for
AbstractEMFOperations that are executed while a non-EMF composite operation is open on the history.

Transaction: Workspace Validate-Edit Support

Transactions perform a new validate-edit step in the validation phase of commit. When a root transaction commits, it now checks that the resources affected by the transaction are writable or can be made writable by the appropriate Team Providers. If any resource is not writable, the transaction rolls back.

A new
Transaction::OPTION_VALIDATE_EDIT option allows clients to specify whether to perform validate-edit or not (by default, not). Additionally, instead of a boolean value, a custom implementation of a new
ValidateEditSupport interface can be supplied to perform a validate-edit better suited to the client's needs. The default implementation simply checks with the editing domain that the resource is not read-only.

The org.eclipse.emf.workspace plug-in
specializes the validate-edit support for its editing domains to use the Eclipse Workspace API for validate-edit. This provides a richer team-provider integration in IDE applications.

Because validate-edit is not enabled by default, clients that wish to use it must specify the OPTION_VALIDATE_EDIT on every command or operation execution. To simplify this, the
TransactionalEditingDomain interface is extended to support default transaction options. Concrete editing domains may implement a new
Adaptable interface to provide a
DefaultOptions adapter that allows clients to set and query domain-wide default transaction options. The best opportunity for specifying default transaction options is in the factory implementation for the editing domain, so that they are in place before any client actually creates any transactions in that domain.