maven-doxia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Theussl <>
Subject Re: svn commit: r598803 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/sink/ doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/ doxia-modules/doxia-module-fo/src/main/java/org/apac...
Date Thu, 29 Nov 2007 09:02:23 GMT


We had a discussion about EOLs some time ago, I would like to know which 
tests failed for you. The AbstractSinkTest (which all sink tests are 
supposed to extend) filters out every EOL in the strings it compares (my 
reasoning for that was that the case where EOLs are significant is 
usually a special case and should be tested separately).

Apart from that, IMO AbstractXmlSink is an abstract base class that 
shouldn't be concerned with formatting (btw, I just noticed that 
writeStartTag also appends an EOL after simple tags, that should be 
removed as well). The writeEndTagWithoutEOL() method is simply not 
needed because implementing sinks should write the EOLs where they need 
them. In the current case, it should be enough to move the EOLs into the 

If tests fail after that then it's probaby the tests that need to be 


PS Are you saying you are using site-plugin beta-6 with doxia beta-1? I 
haven't been able to make the two work together yet...

Hervé BOUTEMY wrote:
> Le mercredi 28 novembre 2007, Lukas Theussl a écrit :
>>Thanks for fixing this! Just two questions:
>>Why do we need a separate method in AbstractXmlSink, can't we just
>>remove the EOL from writeEndTag()?
> I tried to do so in the first place: that's exactly what I wrote when mailing 
> to maven-dev.
> But when doing so, I discovered 2 drawbacks:
> - the whole generated HTML document was without any EOL, which is quite hard 
> to read. But no major problem here, I just thought that people who had 
> written these newlines prefer readable HTML, and wouldn't be happy if I 
> changed their "way of code" :)
> - unit test were failing, since some sinks use LineBreaker class which adds a 
> newline when larger than 78 chars: the whole unit tests logic had to be 
> reworked...
> Then I discovered where really these newlines were a problem, and where they 
> were not: see next paragraph...
>>And what's the reason for selecting only special tags to write no
>>newline? Just because they are inline elements? This doesn't solve the
>>issue of EOLs within <pre> tags, right?
> Yes, because they're inline elements: HTML <a>, <i>, <b> and <code>.
> <pre> tag, you don't use other tags, which are structural tags: you only use 
> inline elements for styling and links/anchors.
> FYI, here is a page on which I discovered the problem when using 2.0-beta6
> Feel free to check and comment this logic, because I think it is good but I'm 
> not 100% sure I didn't miss a special case...
> regards
> Hervé

View raw message