[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248527#comment-17248527
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/13/20, 8:13 AM:
-------------------------------------------------------------------------
As for explanting the code from IDEA, that would be a bit difficult because the
class has many dependencies and this statement applies recursively. What the
code basically does, though, is to count all the different types of line breaks
CR, LF and CRLF and return the one with the highest count in the file. Doing
all this, it also takes care of encoding issues, BOM headers in XML files etc.,
so it is quite sophisticated. But a simple version might be easy to reimplement.
Anyway, I do not like the approach much and had the idea to modify Maven
Release in such a way that, if a certain new option
{{preserveOriginalLineBreaks}} is specified, instead of normalising line
endings while reading the XML file and writing back with a uniform line ending,
it could encode all line endings as XML entities {{
 ;}} and {{
 ;}} and
just write them back out in a decoded way after POM modification. What do you
think about that? It would even preserve a file with mixed line endings and
would eliminate the need to detect the most common line ending type via
statistics.
was (Author: kriegaex):
As for explanting the code from IDEA, that would be a bit difficult because the
class has many dependencies and this statement applies recursively. What the
code basically does, though, is to count all the different types of line breaks
CR, LF and CRLF and return the one with the highest count in the file. Doing
all this, it also takes care of encoding issues, BOM headers in XML files etc.,
so it is quite sophisticated. But a simple version might be easy to reimplement.
Anyway, I do not like the approach much and had the idea to modify Maven
Release in such a way that, if a certain new option
{{preserveOriginalLineBreaks}} is specified, instead of normalising line
endings while reading the XML file and writing back with a uniform line ending,
it could encode all line endings as XML entities {{
}} and {{
}} and
just write them back out in a decoded way after POM modification. What do you
think about that? It would even preserve a file with mixed line endings and
would eliminate the need to detect the most common line ending type via
statistics.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -----------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
> Reporter: Ralph van Etten
> Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
