On Mon, Jan 17, 2011 at 08:48, Lukas Theussl <[email protected]> wrote:
> > Ok, I get it. The xdoc should be written with the same encoding that is > used when it is read to generate the final report, which is > project.build.sourceEncoding (by default). > > No, it shouldn't. The xdoc xml file should be written with the encoding specified in the xml prolog. I tried the latest snapshot and the prolog defines UTF-8 but the text is written with the encoding specified by project.build.sourceEncoding. If project.build.sourceEncoding is something other than UTF-8, non-ascii chars are garbled if properly reading the XML (i.e. honoring the encoding specified in the xml prolog). /Anders > I fixed it, thanks! > -Lukas > > > > Benjamin Bentmann wrote: > >> Lukas Theussl wrote: >> >> I am confused indeed. I simply used MPLUGIN-180 to verify it works, but >>> just realized it's not good because both input and output encoding are >>> the same there. >>> >> >> Right, it gets only interesting if the two encodings have different >> values, e.g. setting project.reporting.outputEncoding=ISO-8859-1 in >> Anders' example project will yield garbage from "mvn site". >> >> However, the problem is not that the generated report has the wrong >>> encoding, rather the generated, intermediate xdoc, from which the report >>> is generated (run 'mvn site:site' and 'mvn plugin:xdoc' on the attached >>> test project and compare the generated xdoc). For writing this, I would >>> have thought one should use the outputEncoding parameter? Tell me if I'm >>> wrong and I'll change it. >>> >> >> The intermediate xdoc is produced by the PluginXdocGenerator from >> previously extracted MojoDescriptors. It is hard-coded to use UTF-8 for >> the encoding of the generated xdoc. All fine here. >> >> "site:site" invokes PluginReport whereas "plugin:xdoc" invokes >> XdocGeneratorMojo. The latter extending AbstractGeneratorMojo will use >> the proper/configured encoding when reading the Java sources to extract >> the mojo descriptors and eventually generates proper xdoc. But >> PluginReport in version 2.6 uses the wrong encoding (platform default) >> and as such produces bad MojoDescriptor instances upon source parsing. >> Bad MojoDescriptor -> bad xdoc. >> >> So the encoding issue doesn't happen on the output/report side, it >> happens on the input/source side, the bad output is just a followup >> error. The proper fix is to align PluginReport with the encoding >> handling done in AbstractGeneratorMojo such that the source files >> consistently get parsed with the same/configured encoding when calling >> the mojo scanner. >> >> >> Benjamin >> >> --------------------------------------------------------------------- >> 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] > >
