Re: [Clirr-devel] message strings in reports

[<lak...@t-...>]

Simon Kitching wrote:

>Hi,
>
>Currently, when api differences are reported, the check generating the
>report manually builds the difference "description" string. This has a
>couple of problems.
>
>Firstly, multi-language support can't be done. It would be nice to be
>able to provide clirr reports in languages other than english 
>

+1

Personally I would like to see an option to enforce english messages, as 
usually all other dev tools I use are not localized (IDE, Java compiler, 
etc.). I find switching between languages harder than using a foreign 
language consistently - but maybe that's just me.

Technically this is no problem, we have that in Checkstyle.

>(German
>and French translations shouldn't be too hard to arrange :-).
>
>  
>

:-)

>More importantly, the current messages tend to be terse. In many cases,
>I think it would be desirable for differences to be able to reference a
>longer description of the problem, eg "for more info, see issue #7 in
>the clirr docs", where clirr documentation has a couple of paragraphs
>explaining why issue #7 is a binary incompatibility, or why it is a
>warning and under what circumstances problems can occur.
>
>  
>

Yes, very good idea!

>I propose that some kind of "ReportMessage" class be created that is
>capable of reading messages from an external resource file. When checks
>report differences, they indicate just "Message #7" rather than build
>the exact string.
>

Or maybe use message keys like "removedMethod" instead of just numbers? 
That might make maintainance of resource bundles a bit easier. We could 
also introduce some constants (REMOVED_METHOD) in the ApiDifference 
class... we'll see, I'm sure we can work out those details later.

> The ApiDifference class can then use the ReportMessage
>class to build the "short description" (potentially using the standard
>Java string interpolation syntax of {0} and {1} to insert class and
>method/field names). The message code can also be used to reference an
>external doc that describes the problem in more detail.
>
>
>Thoughts?
>
>  
>

Sounds great!

Lars