Provide simple sorting based on the content of SCM commit messages on the HTML report.

Purpose:
In our company we have a 'pre-commit' hook script set up for all projects, that requires from developers to fulfill some formatting rules of SCM commit message. We would like to leverage from this rules and reflect them also on the HTML change log to have a more comprendious and well-arranged change log report. We would like to have commit messages sorted and placed in several additional columns (instead of having them all in one 'Detail' column) in a table on HTML report based on their format and content.

Example:
Suppose you want to divide SCM entries displayed on HTML report into four columns labeled as "Bug fixes", "Features", "Improvements" and "Other changes" in this order. Commit messages that contain at the beginning of the line string "[B]" shall be placed in the "Bug fixes" column, messages with "[F]" at the beginning shall come in the "Features" column, and messages with "[I]" shall come in the "Improvements" column. All other messages shall reside in the last "Other changes" column.

To see an example of how can such customized report look like, see screenshot added as attachment (sample-sorted-report.png).

I implemented a patch (see changelog-sorting-comment.diff) that contains logic that performs sorting of SCM entries as described above and I did it in a general way, so that other users of changelog-plugin can define their own rules for sorting messages. So, with my implementation, you can customize report layout as described in above example by providing three new plugin configuration parameters:

• commentSortRegexPattern=^[[BFI]]
  • Standard java regex pattern that is used for searching a match in commit messages.
  • In this case, it matches commit messages that begin with "[B]", "[F]" or "[I]" string
• commentSortMatchValues=[B],[F],[I]
  • Possible values of result of matches found by above pattern.
  • Used to determine number and order of newly created columns. Also defines which message is placed into which column (messages with [B] at the beginning will be placed in the first column, [F] in the second column, and so on ...).
• commentSortColumnHeaders=Bug fixes,Features,Improvements,Other changes
  • Header titles for newly created columns.
  • They matches the order and number of 'commentSortMatchValues' values, but with one last additional value that is used as a header title for last column, where all 'unsorted' messages will be placed.
    Complete documentation of these parameters is included in my implementation as javadoc.

What I did in the patch:

• 1. I modified 'ChangeLogReport" class as follows:
  • a) I added three new plugin parameters:
    • commentSortRegexPattern
    • commentSortMatchedValues
    • commentSortColumnHeaders
    • including comprehensive documentation - see source code in the patch.
  • b) I added call to newly created method "validateCommentSortParams()" to main "executeReport" method. As it is obvious from its name, this method performs validation of above mentioned three parameters (including different combinations of parameters configuration).
  • c) I slightly modified method "doChangedSetTable" to support creation of new additional column headers used for sorting SCM commit messages. These headers are created only if above mentioned plugin parameters are specified. Otherwise code behaves exactly as it behaved before my change.
  • d) Original method "doChangeSetDetail" was extended with little bit of new logic that distributes SCM messages together with changed files into new columns - if comment sorting functionality is enabled. Because of that, I needed to extract code that deals only with 'detail' column to a separate method - now called "doChangeSetEntryDetail". Finally, I renamed original "doChangeSetDetail" method to "doChangeSetEntry" name, because it deals with whole entry (one row in HTML table including timestamp and author columns) and not only 'detail' part - just to improve a readability of code.
• 2. I modifies "ChangeLogReportTest" class:
  • f) I add some integration tests that tests both correct and wrong combination of configuration parameters to "ChangeLogReportTest" class.

If there is something else to do in connection with this patch, please let me know and I can do it. If this patch could be accepted and included in official release of plugin, I would be grateful and I am also willing to provide any following required bug fixes to this functionality.