Build a changes report by parsing svn comments

I'm not agree with this implementation, we have Maven-SCM for all scm communications and we must use it in maven plugins.

I do agree with you Emmanuel but I had to many problems with Maven-SCM.
I had overriden it so that I could have XML output but :

• I couln't get the outputstream to parse it (my fault lacking time)
• the svn-scm provider was looping over all files to get comments and this is not necessary with svn as comments are per release and release are per project. I didn't have enough time to change my implementation or correct this phenomenon.

I think that the first part should be easy to change using plexus-utils.
As for the second sorry i didn't get deep enough into Maven-SCM :o(.
This plugin is more a proof of concept in my opinion and if you could give some advice I will try to improve it.

Moreover, to be merged, your patch should be in 1.4

This is the same plugin but rewritten for JDK 1.4

I have updated the code. Now it is Java 1.4 and it uses maven-scm API.

JIRA already has a plugin that integrates with SVN and its grammar is:

• [JIRA_ID] Commit comments

How does that match against the grammar(s) provided?

Well, we provide 2 grammar but of course this can be easily extended.
We differ from JIRA (as far as I understand your question) in the fact that we added the type of operation to the bug id.
Let's say that you have fixed a bug and added a feature.
You would have
[add:id1]First implementation of feature
[fix:id2]Really a simple bug
This would add en entry in the changelog with two lines and links to the corresponding entries in the bug tracker.
Also, we currently support JIRA and gforge as trackers but we could add other tools. Moreover since the bug tracker can be configured with a url pattern, you can simply access most of the trackers.

I could provide an example of the page generated and the comments from the subversion repository of this mojo if you think it could help. They willuse the MANU grammar I am afraid since I developed some of it.
Emmanuel

Site and results from the follwoing commands

svn list --xml svn_repo/tags > tags.xml
svn log --xml svn_repo/trunk > entries.xml

This is for a whole new plugin - rather than a changes to the maven-changes-plugin? Because this JIRA project is for the Apache maven project's maven-changes-plugin. If you want to donate it to either to Apache maven or to codehaus (its packaged as "codehaus") then you probably either need to file an issue ticket somewhere else or raise/propose it on a mailing list.

If its for Apache maven then it also needs to be re-packaged as "org.apache.maven", license headers added to the source files and all the francetelecom references removed.

Well, this gives the same report as the changes plugin so that 's why i submitted it there.
The first 2 submits were org.apache but since it looks like the community is not interested I was in the process of migrating the code to codehaus when in a last attempt I submittted it.
Nobody seems to be interested in what this plugin do but more in how it is packaged.
Hope it will have a good life on codehaus....

The other day, I had a look at the generated site that you attached to this issue. When you first proposed this plugin on the dev-list I couldn't understand how it would work and how it differed from maven-changelog-plugin. I understand that better now.

To me it seems that the input and output of your plugin is somewhere in-between maven-changes-plugin and maven-changelog-plugin. However I can't see a good way to integrate it into either one. The changes plugin produces a report based on an issue tracking system. Currently we support changes.xml file and JIRA as issue trackers. Your approach of parsing the commit messages from an SCM doesn't fit well into that. We have a saying where i live. It goes something like this:

"Don't cross the river to fetch water"

That pretty much describes how I feel about your plugin. Why would you want to ask the SCM about issues that are already tracked in an issue tracker? It seems like an extra, and unnecessary, step. Just ask the issue tracker directly. You are bound to get better texts to put in the report than you would by parsing SCM messages.

Thank you Dennis, this is a constructive remark :o)
I agree with you that why I contacted both teams.
The changes.xml is maintained by hand and I think that is far easier as a developer to add more comments to my scm commit than to edit afterwards an xml file to add an entry and then commit it.
If your opinion is "Just ask the issue tracker directly" then why does the changes plugin exist ? Isn't it its goal to provide such a report ? (By the way I notice that most of the teams use JIRA report when they release a new version and not the changes-plugin).
I agree, an improvement would be to fetch the issue comments in the tracker ( version 2.0 ? ) .
I accept your opinion, even if I have 3 teams using it here ;o) (maybe because we don't have JIRA).
But why people asked for modifications (like jdk version, scm-api,package, ...) instead of just stating the fact that they don't think it's a good idea ?

I agree with Emmanuel.
Honestly, I found very strange how this issue was manage.
Rather than stating if the proposed improvement is interesting or not, people always asked for more and more modifications (something like they don't want it but they don't tell it and explain why).

Thanks Denis, for your comments that is constructive.

In my opinion, I think this is an improvement of the maven-changes-plugin because both of them (emmanuel improvement and maven-changes-plugin) have the same report result.

As emmanuel mentionned, the maven community seems to do not understand the interest of this improvement because it uses JIRA.
But not all people uses JIRA and have this functionality integrated with their issue tracker. We can look for instance at the number of vote 17 (for the moment). I don't think that the maven-changes-plugin is just or JIRA users.

Now, we can regret that we have two plugin (maven-changes-plugin and svnchangelog-maven-plugin) that generate the same report but from a different data source.
I think it's more confusing for maven users who won't understand this situation.

I think that it would be nice to add a new goal for the maven-changes-plugin for this improvement and perhaps another to fetch the issue comments from the tracker.

Thanks to Emmanuel and Rémy for your feedback.

I agree when you say the this issue has not been handled well from our side. First we should assess whether or not the idea of the submission is good or bad. If we like it, then we can make suggestions or demands on packaging, code style, licensing and such issues. Sorry about that. We'll try to do better in the future.

The changes.xml file for me is a "poor mans issue tracker". Dead simple to use for anyone, even those that don't even have an SCM to store their source code.

Judging by your comments I must have misunderstood how the plugin works. Are you saying that it can be used without an issue tracker?

Have you guys looked at maven-changelog plugin? It fetches the commit message from your SCM and produces a report of every commit made. See for example:
http://maven.apache.org/plugins/maven-changelog-plugin/changelog.html

Perhaps we could integrate your Commit Message Parser into that plugin instead? Thereby being able to mark the commits by type; add, fix etc.

Well we use the issue tracker as in the changes.xml, just to link to the issue. You must define a tracker type with a tracker url (the typ is used for a regexp to put the bug id in the url) . So if you define a tracker url of '# ' it will work without a bug tracker. Also the id is not mandatory so this way you won't need a tracker. I was in the process of providing a NoneTracker implementation to simplify this, as well as a support for Mercurial.
We keep only the messages which respect the grammar, dismissing the others. The changelog team considered this to be closer to the changes plugin that is why I posted there, but of course if it appears to be more convenient with the changelog plugin I won't object ;o)
The code on codehaus is more recent with full site generated, better documentation (or so I hope) and a good example of configuration.

Just to to be up to date :
the support of Mercurial is done. I have tried to be as close as possible to the maven-scm-api but there is a limitation due to the fact that the ChangeSet doesn't provide a revision number (which is accessible in mercurial and svn), so i have to modify the code of the providers (an give my own implementation). With this simple correction I would be able to be scm agnostic.
Dennis, I have confirmed that setting the <trackerUrlPattern>#</trackerUrlPattern> does eliminate the need of a tracker.
I hope to release this new version on codehaus soon.
Emmanuel

Support for Hg.
Packaged as codehaus plugin but I will hapilly change back to Apache if it is needed.