Please ignore my previous mail. For sake of clarification, I'll re-post to an empty thread.
Sorry for the trouble. Denis. > -----Message d'origine----- > De : Cabasson Denis [mailto:[EMAIL PROTECTED] > Envoyé : mardi 17 juillet 2007 15:06 > À : Maven Developers List > Objet : Revert doxia revision 555417 > > 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-cor > e/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-plu > gin/src/main/java/org/apache/maven/plugin/pmd/AbstractPmdRepor > t.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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
