You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2011/01/16 14:31:49 UTC
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Hi Lukaus,
> Author: ltheussl
> Date: Sun Jan 16 13:14:04 2011
> New Revision: 1059551
>
> URL: http://svn.apache.org/viewvc?rev=1059551&view=rev
> Log:
> [MPLUGIN-180] forward encoding to the PluginToolsRequest
>
> Modified:
> maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
>
> Modified: maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
> URL: http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java?rev=1059551&r1=1059550&r2=1059551&view=diff
> ==============================================================================
> --- maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java (original)
> +++ maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java Sun Jan 16 13:14:04 2011
> @@ -91,6 +91,13 @@ public class PluginReport
> */
> protected MojoScanner mojoScanner;
>
> + /**
> + * @parameter expression="${outputEncoding}" default-value="${project.reporting.outputEncoding}"
> + * @since 2.7
> + */
> + private String outputEncoding;
> +
> +
> /**
> * Specify some requirements to execute this plugin.
> * Example:
> @@ -183,6 +190,7 @@ public class PluginReport
> pluginDescriptor.setDependencies( PluginUtils.toComponentDependencies( project.getRuntimeDependencies() ) );
>
> PluginToolsRequest request = new DefaultPluginToolsRequest( project, pluginDescriptor );
> + request.setEncoding( outputEncoding );
>
> mojoScanner.populatePluginDescriptor( request );
This is wrong, you confuse the source input encoding with the report
output encoding. From the javadoc of PluginToolsRequest.setEncoding():
"Sets the file encoding of the source files."
The proper fix should be to align the report mojo with the other mojos
and use
/**
* The file encoding of the source files.
*
* @parameter expression="${encoding}"
default-value="${project.build.sourceEncoding}"
* @since 2.7
*/
protected String encoding;
as the encoding parameter for the request.
The output encoding for the docs is handled by the Site Plugin AFAIK,
isn't it?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Jörg Schaible <jo...@scalaris.com>.
Hi Lukas,
Lukas Theussl wrote:
> Anders Hammar wrote:
>> On Mon, Jan 17, 2011 at 08:48, Lukas Theussl<lt...@apache.org> 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.
Which implies UTF-8 by XML specification ;-)
> But the xml
> encoding declaration should of course match the actual file encoding.
It has to, otherwise the XML is simply invalid.
>> 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).
The XML parser will throw an exception in worst case (if the read garbage
does no longer result in a defined UTF-8 character).
> 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... ;)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Anders Hammar <an...@hammar.net>.
I'll attach to MPLUGIN-180. Please reopen that.
/Anders
On Tue, Jan 18, 2011 at 09:10, Lukas Theussl <lt...@apache.org> wrote:
>
>
> Anders Hammar wrote:
>
>> On Mon, Jan 17, 2011 at 08:48, Lukas Theussl<lt...@apache.org> 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: 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
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Lukas Theussl <lt...@apache.org>.
Anders Hammar wrote:
> On Mon, Jan 17, 2011 at 08:48, Lukas Theussl<lt...@apache.org> 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: 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Anders Hammar <an...@hammar.net>.
On Mon, Jan 17, 2011 at 08:48, Lukas Theussl <lt...@apache.org> 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: 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
>
>
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Lukas Theussl <lt...@apache.org>.
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).
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: 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
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Benjamin Bentmann <be...@udo.edu>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r1059551 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
Posted by Lukas Theussl <lt...@apache.org>.
Benjamin Bentmann wrote:
> Hi Lukaus,
>
>> Author: ltheussl
>> Date: Sun Jan 16 13:14:04 2011
>> New Revision: 1059551
>>
>> URL: http://svn.apache.org/viewvc?rev=1059551&view=rev
>> Log:
>> [MPLUGIN-180] forward encoding to the PluginToolsRequest
>>
>> Modified:
>> maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
>>
>>
>> Modified:
>> maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
>>
>> URL:
>> http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java?rev=1059551&r1=1059550&r2=1059551&view=diff
>>
>> ==============================================================================
>>
>> ---
>> maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
>> (original)
>> +++
>> maven/plugin-tools/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
>> Sun Jan 16 13:14:04 2011
>> @@ -91,6 +91,13 @@ public class PluginReport
>> */
>> protected MojoScanner mojoScanner;
>>
>> + /**
>> + * @parameter expression="${outputEncoding}"
>> default-value="${project.reporting.outputEncoding}"
>> + * @since 2.7
>> + */
>> + private String outputEncoding;
>> +
>> +
>> /**
>> * Specify some requirements to execute this plugin.
>> * Example:
>> @@ -183,6 +190,7 @@ public class PluginReport
>> pluginDescriptor.setDependencies( PluginUtils.toComponentDependencies(
>> project.getRuntimeDependencies() ) );
>>
>> PluginToolsRequest request = new DefaultPluginToolsRequest( project,
>> pluginDescriptor );
>> + request.setEncoding( outputEncoding );
>>
>> mojoScanner.populatePluginDescriptor( request );
>
> This is wrong, you confuse the source input encoding with the report
> output encoding. From the javadoc of PluginToolsRequest.setEncoding():
>
> "Sets the file encoding of the source files."
>
> The proper fix should be to align the report mojo with the other mojos
> and use
>
> /**
> * The file encoding of the source files.
> *
> * @parameter expression="${encoding}"
> default-value="${project.build.sourceEncoding}"
> * @since 2.7
> */
> protected String encoding;
>
> as the encoding parameter for the request.
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.
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.
Thanks for looking!
-Lukas
>
> The output encoding for the docs is handled by the Site Plugin AFAIK,
> isn't it?
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> 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