[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248307#comment-17248307
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/12/20, 8:17 AM:
-------------------------------------------------------------------------
[~michael-o], I was not talking about an editor but about Git. Git is an SCM,
not an editor. The entity editing the POM is this plugin!
Um, of course it would be nice to have a little line detector tool in Commons
IO. But why push off this requirement to another project -if a change in this
one caused something which was previously working to suddenly break-? Why not
implement a solution here first and then let Commons IO maintainers decide if
they want to take over the functionality in identical or similar form? After
that and totally decoupled from the Commons IO release cycle, you could still
transition/migrate to the solution in that library.
*Edit:* Sorry, ** this issue is so old I remembered wrong. Probably the
plugin's behaviour has not changed but the problems are caused by a change
within Git for Windows which they refused to fix when asked a few years ago. I
struck through the incorrect part of my previous statement above. My apologies
for mixing up things in my faint memory.
If anyone likes to take a look at a seemingly quite sophisticated line
detector, IntelliJ IDEA has something like that:
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L664-L684]
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L718-L743]
I did not look into the details, but maybe this is something to get inspiration
from.
was (Author: kriegaex):
[~michael-o], I was not talking about an editor but about Git. Git is an SCM,
not an editor. The entity editing the POM is this plugin!
Um, of course it would be nice to have a little line detector tool in Commons
IO. But why push off this requirement to another project if a change in this
one caused something which was previously working to suddenly break? Why not
implement a solution here first and then let Commons IO maintainers decide if
they want to take over the functionality in identical or similar form? After
that and totally decoupled from the Commons IO release cycle, you could still
transition/migrate to the solution in that library.
> 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)
