I'll attach to MPLUGIN-180. Please reopen that. /Anders
On Tue, Jan 18, 2011 at 09:10, Lukas Theussl <[email protected]> wrote: > > > Anders Hammar wrote: > >> 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. >> > > Well, the xdoc is generated, so there is no xml prolog yet. But the xml > encoding declaration should of course match the actual file encoding. > > > >> 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). >> > > > Then my guess is that PluginXdocGenerator writes the wrong prolog. Can you > construct a test case? I hate encoding issues, but since I was stupid enough > to try to fix it... ;) > > -Lukas > > > > >> /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] >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
