Description Jan Koehnlein 2013-02-15 08:24:55 EST

I've writen a number of new validation rules recently, and I must admit that I still have to look up every time which variant of error(...), warning(...) etc. fits my needs and in which order the parameters have to be specified. 

Given that I spent a little time to develop a builder API for creating issues and integrate it with as little footprint as possible. So instead of writing

error("The method " 
  + notNull(operation.getSimpleSignature()) 
  + " of type " 
  + notNull(operation.getDeclaration().getDeclaringType().getSimpleName()) 
  + " must override a superclass method.", 
  function, 
  XTEND_MEMBER__MODIFIERS, 
  function.getModifiers().indexOf("override"), 
  OBSOLETE_OVERRIDE);

one can now write

error("The method {0} of type {1} must override a superclass method.", 
  operation.getSimpleSignature(), 
  operation.getDeclaration().getDeclaringType().getSimpleName())
 .element(function)
 .feature(XTEND_MEMBER__MODIFIERS)
 .index(function.getModifiers().indexOf("override"))
 .code(OBSOLETE_OVERRIDE)

and 'element', 'feature', 'index' and 'code' can be skipped in case the defaults (currentElement, null, -1, null) are OK.

I attach a patch with my changes. Unfortunately, it adds another variant of error(), warning() etc. Into the bargain, not requiring the user to explicitly finish an issue build adds some addtional state to be managed.
OTOH, the new methods would obsolete all the others. It should also work well with the new configurable issues. 

I am not sure if we should apply this or rather go for a completely new API some day, maybe based on Xtend.