Hervé BOUTEMY wrote:
from a user point of view, why not: it will require more code from us to mimic
this, but the logic seems ok for me
You're right, the logic itself is not that bad. My remaining concern is
the minimal POM where we don't have a fixed source encoding, causing
platform-dependent site output.
but I suppose that the warning when source encoding has not been set will help
people to rapidly define their source encoding.
Then both choices for default output encoding will be equivalent on
this "build reproducibility" side.
Sounds convincing. This way, users have already two reasons to specify
this property: Reproducible build and site ;-)
The remaining difference is code complexity: fixed UTF-8 is simpler to code
than calculated source encoding.
Well, just as Vincent did for the Javadoc plugin:
/**
* @parameter default-value="${project.build.sourceEncoding}"
* @readonly
*/
private String sourceEncoding;
private String getSourceEncoding()
{
return ( sourceEncoding != null ) ? sourceEncoding :
ReaderFactory.FILE_ENCODING;
}
private String getOutputEncoding()
{
return ( outputEncoding != null ) ? outputEncoding :
getSourceEncoding()
}
Not too much, we only need to properly document this pattern, especially
to promote it to Non-Apache plugins as well.
What might be interesting is what logic the majority of users prefers.
In general, source files and report output are distinct kind of stuff,
i.e. if one uses Latin-1, Big5 or whatever for sources, do they want the
same for reports are rather something more international like UTF-8 as
requested in MSITE-224?
Anyway, as long as we come up with a solution applicable to all report
plugins, that's fine.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
