Bug 24882

Description Roberto Scaramuzzi 2002-10-16 19:38:06 EDT

Usage:

We are developing a plugin for eclipse that will be able to run various
kinds of tests (coding standards, unit tests, uncaught runtime exceptions,
etc.) on Java code.

There are several usage cases for this plugin, but I want to concentrate
on the interaction with source control.

In this usage case, a developing team will have a policy that code needs to
pass all tests before it is checked in. We would like to facilitate this
by integrating the testing procedure with the checkin procedure.

Similar situations that the community may be interested in are regression
test success or syntax checking (for example, for xml, .project or
.classpath files) before code or configuration files are checked in.

While this last example could be accomplished on the CVS server through
use of the commitinfo feature, our situation and the first example might
be tricky to implement because of platform differences. 

Additionally, we plan to provide feedback on the errors found, as well as
easy methods to correct these errors. These features are local in nature and
do not lend themselves well to a client-server model.

Technical issues:

1. Ensuring there is no performance penalty for the case where there is no
   verification required.

   I don't see a problem. The nameFilter option below should help, in case I
   am wrong.

2. Does failure of one file mean failure of the entire commit?

   I suggest that this be left up to the validator implementation. 
   The commit validator should return should return an IStatus object. 
   If isMultiStatus() returns false for this object, the whole commit should be
   aborted in case of a failure. If it returns true, the commit should
   be aborted only for the specific files that caused failures.

3. How do you handle multiple plugins using the same extension:  what order
do the commit validators run in, if one fails is it failure for the other
validators, etc?

    The validators should not modify the validated resource by contract.
    Hence the order of validations is irrelevant. Obviously the commit
    should fail if any of the validators fail. Efficiency might dictate
    aborting the validation process as soon as one validation fails,
    but I do not think this is for the best. The user will want to know
    about all errors before she starts to correct them.

4.  What does the extension point look like?  For example, what contextual
information would the validator require (is it just the file that's being
committed?).

    The validator should be able to run given just an IResource object.
    However, there should be provisions in the extension point for filters
    (for example, the validator might only need to be run for Java source
     files).

Proposed design:

1. New classes, interfaces, methods

a. PreCommitEvent:  
   The team plugin should fire a pre-commit event to registered listeners

b. CommitValidatorManager: instantiated by the Team plugin, maintains
   a list of validators and filters. It listens for pre-commit events.
   On each such event, runs the validate() method of the appropriate
   validator(s), aborts the commit and displays a message if any
   of the validators return other than IStatus.OK

c. ICommitValidator: the interface that the validators provided by clients
   should implement. It has just one method:
   
   org.eclipse.core.runtime.IStatus validate(org.eclipse.core.resources.IResourcee);

   This method should promise not to change the content or other attributes
   of the validated file (to insure commutativity of the validators).

2. Extension markup (sorry, but I don't know how to write DTDs) could
   be modeled on the following example.

<extension point="org.eclipse.team.commitvalidator">
    <validator id="com.xyz.myvalidator"
               class="com.xyz.MyValidator"
               nameFilter="*.java"/>
</extension>

Additional thoughts:

An idea is to let the user add external validators, similar to the
external tool builders used in the build process. In order to do this
the Team plugin would plug in to its own extension point with a class that
reads a configuration file, runs a specific binary or batch file and
gets the status from the exit code of the process. Variables could be passed
to the executable by a mechanism similar to that available for external
tools builders