maven-doxia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
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 18:12:13 GMT
Le jeudi 29 novembre 2007, Lukas Theussl a écrit :
> Hi,
>
> 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
> XhtmlBaseSink.
>
> If tests fail after that then it's probaby the tests that need to be
> adapted...
>
> Cheers,
> -Lukas
>
> 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...
I forgot: no, I didn't test the full stack Doxia + maven-site-plugin
I just found in Doxia unit tests the cause of the problem

>
> Hervé BOUTEMY wrote:
> > Le mercredi 28 novembre 2007, Lukas Theussl a écrit :
> >>Herve,
> >>
> >>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>.
> > Within <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 http://logdistiller.sourceforge.net/quickstart-4.html
> >
> > 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é
> >
> >>Cheers,
> >>-Lukas



Mime
View raw message