Could you please revert the Doxia revision : http://svn.apache.org/viewvc?view=rev&revision=555417
And deploy a new snapshot version of doxia since latest version (doxia-core-1.0-alpha-9-20070714.200033-13) is shipping with this patch. This patch is breaking report created by lots of plugin. Indeed links beginning with "./some/path/file.html" are no longer considered as local link on my configuration (Windows with French Locale) and ends up as links to anchor : href="#./some/path/file.html". This can be tracked to the fact that http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/sink/StructureSink.java?revision=519803&view=markup StructureSink#isExternalLink is using File.separator to search for relative links (which is '\' instead of '/' on windows), while most of the report plugin are just using the '/' char (for example, see http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/src/main/java/org/apache/maven/plugin/pmd/AbstractPmdReport.java?revision=517080&view=markup AbstractPmdReport#constructXRefLocation ). Before revision 555417, everything was fine but with this revision, a lots of reports are broken here, with relative links being now wrongly considered as links to anchors. I guess http://jira.codehaus.org/browse/DOXIA-47 should be reopened, and another solution found (or maybe StructureSink should be more lenient on the separator char). Thanks! Denis. > -----Message d'origine----- > De : Mark Hobson [mailto:[EMAIL PROTECTED] > Envoyé : mardi 17 juillet 2007 10:44 > À : Maven Developers List > Objet : Re: MNG-612 > > Hi Jason, > > The collector resolves conflicts by asking a chain of > ConflictResolvers in turn to see if they can select an > appropriate version. If a ConflictResolver cannot resolve > the conflict, then it simply returns null and the next > ConflictResolver in the chain is consulted, and so on. If > the end of the chain is reached and the conflict still cannot > be resolved, then the collector throws an exception that > fails the build. > > Thus a conflict resolver itself cannot fail the build > directly, but I would consider adding an exception to the > ConflictResolver API. > > So does this mean that this issue may gain some momentum? ;) > > Cheers, > > Mark > > On 17/07/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > Mark, > > > > Just looking at: > > > > http://svn.apache.org/repos/asf/maven/components/branches/MNG-612/ > > maven-artifact/src/main/java/org/apache/maven/artifact/resolver/ > > conflict/ > > > > What happens if you want to bomb? If I wanted to fail the build if > > there is a conflict? I'm asking because someone in a class I was > > teaching wanted to implement that and I said he could use your code > > :-) > > > > Thanks, > > > > Jason. > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
