when using svn, links are wrong

This patch does 4 things:

1. Makes a few vars protected rather than private so that we can assign initial values to them, so that we can unit test. Is there another way to replicate the maven environment?
2. Contains the patch from MCHANGELOG-15, which fixes the index out of bounds error.
3. Adds specific treatment for svn urls in generateLinks()
4. Fixes another bug where only the first changeset has a proper link. This is caused by calling initReportUrls() for every changeset (which then makes rpt_OneRepoParam into an empty string on the second pass), and is fixed by doing it once per table.

These are unit tests, for urls generated by ChangelogReport in the case of svn as your scm. They belong in the src directory. They will work with the unpatched ChangeLogReport.java, iff you make scmUrl and displayFileDetailUrl protected rather than private.

Patch applied. Thanks.

I have reverted the patch for this issue because it breaks the link creation for other svn web presentation systems, most notably viewcvs and viewvc.

Closing as "Won't Fix" beacuse the web presentation system for SCM used in this example seems to be extremely rare. Google turned up 123 hits for "websvncommons" most of which comes from our JIRA or mailing lists.

Dennis, I think you are missing a lot of information. I haven't had time to look in detail, but let me fill you in from what I know, and what I suspect.

1. The decision to close - websvncommons? That is just our URL. Not the name of the presentation system, which is websvn (http://websvn.tigris.org/) Try looking that up in google As far as I know, not just svn, but every web presentation system has a different url for to show the listing of a directory vs the detailed changes or the printout of a file, which was the point of this change. I don't know how you can justify forcing a single URL on developers to cover all potential cases.

2. I suspect that your conclusion that it breaks other systems is wrong. We basically add one 'if' clause to a number of others, to account for this case in particular. The other cases were untouched. That in itself should give you confidence in the patch. We tested it with other systems and it was fine with everyone for over 6 months. So I think there was some other coincidental problem that you encountered. And if there was a problem, how could it be anything more than a trivial fix? Why was the problem never described, at all? I'm sure your new problem would be easy to fix.

So, I'm going to reopen the issue, because I think it's incredibly valuable to be able to click on the link in the changelog, and actually see the file you clicked on (which does not work without such a patch).

The issue is still at large. You should be able to click on a link in your changelog and have it show the file in your web presentation system. Currently, this does not work.

Hi Julian

Glad your're still with us.

1. Well then, now we have something more to go on. I agree that such a presentation system is worth supporting. That was not apparent in the original report though.

Ideally I would like to do something similar to the changes plugin where you can configure a pattern for displayFileDetailUrl with special markers for "file" and "revision" so that you could use:
<displayFileDetailUrl>http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&amp;rev=%REVISION%&amp;sc=0&amp;path=%FILE%</displayFileDetailUrl>

But that I think that requires a lot of plumbing to be replaced. So I would like to wait with such a feature until the next version (2.1) of the plugin.

2. The "if cluse" that is added by the patch hijacks all SVN SCM connections resulting in, at least the ones using viewvc not working properly. For the time being the "if clause" solution is the way to go, until something similar to 1. is implemented, but it has to be transparent to other systems. Is there a distinct signature in URLs for websvn that we can use to check against?

I've linked to the original report. As I remember, we patched, then Maven changed somewhat substantially, which broke this patch, and so we patched again. That's what this report is (was) about. I think you're looking for the original report.

As for distinct signatures, I don't really think there is one, but I also don't think that's necessary. The developer should simply be able to choose what URL they would like to use in order to present files out of their chosen scm. There's no reason why it should break any system at all.

I think the original patch was designed to simply see if the displayFileDetailURL had been set, and only do something if it had. If it wasn't doing that, then there is a bug in the patch, which should be trivial to fix. That is a possible way forward.

BTW your suggestion about the parallel with changes is exactly right.

Thanks,

J

Thanks Julian

This was really helpful. Now I can see the intentions of the original patch. Unfortunately it was not implemented like you wanted it to [1] and that's the reason why it broke other systems. I will try to change the current behavior to the one you intended.

[1] http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changelog-plugin/src/main/java/org/apache/maven/plugin/changelog/ChangeLogReport.java?r1=393154&r2=393180

I have tried different solutions to this and think that I have something that might work. I just need to verify it on a real project. The repo that you mentioned in your original report is no longer available, but I found another one at your site that I'd like to use to test this, if that's OK with you: http://apollo.ucalgary.ca:8800/lc-webapp-archetype/

Unfortunately it requires login and password to view the files. Do you have the possibility to give me access to view the files? You can send me the details to my apache address if you like. Or, perhaps you have another repo that can be used for testing, that doesn't require login.

The patch I created for this has been applied and a new SNAPSHOT version of the plugin has been published. Please try it and see if it solves your problem.

Sorry I have been unavailable again for a while. I'll try and make some time to try out the patch this week. Thanks.

Julian, do you think you could try out the latest SNAPSHOT?

I'd like to release maven-changelog-plugin, and this is the last remaining issue scheduled for 2.0.

Works well for me. Thanks.

J