Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fixed links after Codehaus closing

...

Life would become easier if there was a dedicated POM element like ${project.reporting.outputEncoding} which could be used to specify the encoding once per entire project. Every plugin could use it as default value, like it has been done with source files encoding:

Code Block
java
java

/**
* @parameter expression="${outputEncoding}" default-value="${project.reporting.outputEncoding}"
*/
private String outputEncoding;

Adding this element to the POM structure without breaking backward compatibility can only happen in a future version, yet to be defined (at least after Maven 3.0):

Code Block
xml
xml

<project>
  ...
  <reporting>
    <outputEncoding>UTF-8</outputEncoding>
    ...
  </reporting>
  ...
</project>

For Maven 2.x, the value can be defined as an equivalent property:

Code Block
xml
xml

<project>
  ...
  <properties>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    ...
  </properties>
  ...
</project>

...

  • ISO-8859-1 for maven-site-plugin, maven-jxr-plugin and by extension every reporting plugin generating content with maven-site-plugin's template (that is the vast majority of reporting plugins),
  • UTF-8 for cobertura-maven-plugin,
  • platform encoding for maven-javadoc-plugin.

Unifying default value will lead to a change for plugins previously using another default value. This shouldn't cause much harm since reports are mainly read by humans through their web browser.

...

A check has to be coded in every plugin with the default value:

Code Block
java
java

/**
* Gets the effective reporting output files encoding.
*
* @return The effective reporting output file encoding, never <code>null</code>.
*/
protected String getOutputEncoding()
{
    return ( outputEncoding != null ) ? outputEncoding : ReaderFactory.UTF_8;
}

...

For the record, the other proposed unified default value was source encoding as defined in Source File Encoding proposal, which would vary from project to project. Since users are invited to set a fixed value for source encoding in their poms to ensure build reproducibility, such calculated value wouldn't affect build reproducibility, but wouldn't have been appropriate in every case (for example, if project's description in pom.xml contains characters that can't be output with source files encoding).

...

  • maven-changelog-plugin
  • maven-javadoc-plugin: MJAVADOC-206, done in 2.5
  • maven-jxr-plugin: JXR-67, done in 2.2
  • maven-pmd-plugin: MPMD-83, done in 2.5
  • maven-site-plugin: MSITE-340, done in 2.0

Affected Codehaus plugins:

...

[0] next step for encoding support: reporting output files

[1] MNG-3608