Since it can be set in MAVEN_OPTS issue is maybe not that a big deal.

Le lun. 13 févr. 2023 à 07:22, Christoph Läubrich <m...@laeubi-soft.de> a
écrit :

>  > On the bright side, `System.lineSeparator()` is almost never used
>
> I use that all day long in my code, and probably this will change for
> other classes as well, so relying on that people use the system property
> seems broken by design.
>
> Am 12.02.23 um 23:28 schrieb Piotr P. Karwasz:
> > Hi Elliotte,
> >
> > On Sat, 11 Feb 2023 at 14:02, Elliotte Rusty Harold <elh...@ibiblio.org>
> wrote:
> >> IMHO in 2023 the problem is that anything relies on a system dependent
> >> line.separator instead of explicitly specifying which bytes are
> >> output. I've fixed some instances of that antipattern over the years.
> >> Please file bugs on any plugin you notice that still does that.
> >
> > I agree that "line.separator" should not be used anywhere.
> >
> > Unfortunately it is used whenever `BufferedWriter` or `PrintStream` is
> > used, so the simplest build that uses the "jar" plugin will already be
> > system dependent ("pom.properties" uses the line separator). On the
> > bright side, `System.lineSeparator()` is almost never used: most
> > classes use the current value of the "line.separator" property, not
> > the boot time value.
> >
> > I would be satisfied if Maven plugins started using `BufferedWriter`s
> > with a hardcoded `newLine` method, but for backward compatibility
> > Maven could:
> >
> > 1. Use a separate Maven POM property (e.g.
> > `project.build.lineSeparator`) with alphanumeric values (e.g. `CR`,
> > `LF`, `CRLF`). Plugins can issue a warning if this is not set, like in
> > the case of `sourceEncoding`:
> > https://maven.apache.org/general.html#encoding-warning
> > 2. Set the `line.separator` Java system property to the correct value
> > before any plugin runs: this will not modify `System.lineSeparator()`,
> > but will change the behavior of all `BufferedWriter`s,
> > 3. Ignore `System.lineSeparator()` in the rare plugins that were
> > adapted to use it.
> >
> > Piotr
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Reply via email to