Return-Path: 
 <dev-return-84938-apmail-maven-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-dev-archive@www.apache.org
Received: (qmail 26506 invoked from network); 2 Aug 2008 13:12:18 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Aug 2008 13:12:18 -0000
Received: (qmail 92247 invoked by uid 500); 2 Aug 2008 13:12:12 -0000
Delivered-To: apmail-maven-dev-archive@maven.apache.org
Received: (qmail 92144 invoked by uid 500); 2 Aug 2008 13:12:12 -0000
Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@maven.apache.org>
List-Help: <mailto:dev-help@maven.apache.org>
List-Post: <mailto:dev@maven.apache.org>
List-Id: "Maven Developers List" <dev.maven.apache.org>
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Delivered-To: mailing list dev@maven.apache.org
Received: (qmail 92133 invoked by uid 99); 2 Aug 2008 13:12:12 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Aug 2008 06:12:12 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [212.27.42.65] (HELO smtp8-g19.free.fr) (212.27.42.65)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Aug 2008 13:11:14 +0000
Received: from smtp8-g19.free.fr (localhost [127.0.0.1])
	by smtp8-g19.free.fr (Postfix) with ESMTP id EE97A32A869
	for <dev@maven.apache.org>; Sat,  2 Aug 2008 15:11:39 +0200 (CEST)
Received: from dell-desktop.local (put92-4-82-231-48-193.fbx.proxad.net
 [82.231.48.193])
	by smtp8-g19.free.fr (Postfix) with ESMTP id C449D32A88B
	for <dev@maven.apache.org>; Sat,  2 Aug 2008 15:11:39 +0200 (CEST)
From: =?iso-8859-1?q?Herv=E9_BOUTEMY?= <herve.boutemy@free.fr>
To: "Maven Developers List" <dev@maven.apache.org>
Subject: Re: [VOTE] Release Maven Javadoc Plugin version 2.5
Date: Sat, 2 Aug 2008 15:11:39 +0200
User-Agent: KMail/1.9.9
References: <9ae367340808011901u18db6b53rd73d68b1ef12aa54@mail.gmail.com>
 <9ae367340808020431o38e29508q5dba183de9ac7995@mail.gmail.com>
 <48944DB2.8070302@udo.edu>
In-Reply-To: <48944DB2.8070302@udo.edu>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200808021511.39762.herve.boutemy@free.fr>
X-Virus-Checked: Checked by ClamAV on apache.org

Le samedi 02 ao=FBt 2008, Benjamin Bentmann a =E9crit :
> Vincent Siveton wrote:
> > So by default, we have now:
> > - encoding =3D ${project.build.sourceEncoding}
> > - docencoding =3D ${project.reporting.outputEncoding}
> > - charset =3D null
> >
> > And if charset =3D=3D null, charset =3D 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=E9 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.
>
> > -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.
> 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?
>
> 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 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=E9 has something else to say.
you perfectly summed up the whole logic behind "Report Encoding Configurati=
on"=20
proposal [0], then its Jira issue MNG-3608 [1]
(I forgot to link it to MJAVADOC-206: done now)

Herv=E9

>
>
> Benjamin
>
>
> [0] http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configurati=
on
[1] http://jira.codehaus.org/browse/MNG-3608

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org