2008/8/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Vincent Siveton wrote:
>
>> So by default, we have now:
>> - encoding = ${project.build.sourceEncoding}
>> - docencoding = ${project.reporting.outputEncoding}
>> - charset = null
>>
>> And if charset == null, charset = docencoding
>
> Yes, as per MJAVADOC-182 and MJAVADOC-206, i.e. setting "docencoding" is
> usually sufficient to control the report output.
>
>> Also, I noticed in the Javadoc tool documentation:
>> -encoding "If this option is not specified, the platform default
>> converter is used."
>> Ok Hervé displays a warn about build platform dependent if null but
>> the -encoding param is not passed in the Javadoc tool.
>
> Hm, AbstractJavadocMojo.java:3527 is the line where the mojo's encoding
> parameter is passed to javadoc.Nope. The code passed the encoding parameter *only* if it was not empty. The code didn't take care of this warning (and in fact delegating to the javadoc tool which uses the platform encoding). > >> -docencoding "If you omit this option but use -encoding, then the >> encoding of the generated HTML files is determined by -encoding." >> We need to reflect this logic and NOT using UTF-8 which is actually the >> default. > > But using UTF-8 as the default was the whole intention of MJAVADOC-206. Yes but I think it is not the correct behaviour according the javadoc tool documentation. I fixed it in r681961 (crazy timing!) and I would like to close the issue as won't fix. > Let's consider the bigger picture, i.e. the entire site generation process: > Other report generation plugins might have no "encoding" parameter (e.g. > because they don't read the sources), so those plugins cannot mimic the > logic of the javadoc tool. Say foo-maven-plugin is such a report plugin and > we have this POM snippet: > > <properties> > <p.b.sourceEncoding>Big5</p.b.sourceEncoding> > </properties> > <reporting> > <plugins> > <plugin> > <artifactId>maven-javadoc-plugin</artifactId> > </plugin> > <plugin> > <artifactId>foo-maven-plugin</artifactId> > </plugin> > </plugins> > </reporting> > > This states "Dear Maven, my source files are Big5 but I want my site in > UTF-8 (the proposed default for project.report.outputEncoding [0])". Now > comes the Javadoc Plugin and uses its own historic/proprietary logic to > render the report in Big5 while all the other reports are rendered in UTF-8? > IMHO this user needs to specify all parameters. > Maven plugins often provide a facade over other tools and I feel, in the > spirit of convention over configuration and any other Maven philosophy, we The encoding convention is to specify encoding to make build reproducibility. So I guess that the Javadoc Plugin behaviour is now correct. Cheers, Vincent > have the right to make the plugin behave differently than the underlying > tool. The overall design goal should be to get a smooth build with as less > XML clutter as possible, not to dumbly mimic another tools command line > (which was designed for a completely different use case than a Maven build). > > Just my two cents, maybe Hervé has something else to say. > > > Benjamin > > > [0] http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration > > --------------------------------------------------------------------- > 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]
