25

when i try to run the maven-release-plugin it changes the version in the pom.xml file. Prior to the maven release every line ending has unix style <lf> but after running it on my windows machine, the plugin changes every line in the file to <cr><lf>.

My questions are:

a) Is there a way to tell maven to leave everything as it is or to use a specific line ending

or

b) Is there a general way to tell windows what the line ending should be? Even a tool that hacks something deep down in the OS would be considered helpful.

I had a look at this https://issues.jfrog.org/jira/browse/BI-111 and it says "resolved" but i am using the latest version and it doesn't work for me.

realsim
  • 1,386
  • 3
  • 13
  • 25
  • Does http://stackoverflow.com/questions/2162275/convert-files-to-unix-format-using-maven help you in any way ? – Walter A Feb 16 '15 at 19:25

4 Answers4

8

There are four possible solutions.

  1. Use the Maven Assemly Plugin

I think the best idea is investigate the Maven assembly plugin. It should allow you to update the line separator. See the section "fileSet" section for details.

  1. Use PowerShell to call mvn

As a temporary work around, you can use PowerShell (Start->All Programs->Accessories->Windows PowerShell). Call maven like you would, with some extras around double quoting the -D statements. mvn assembly:assembly -P prod "-Dmaven.test.skip=true". Now add to this -Dline.separator=`n. This should cause PowerShell to add the escaped value.

  1. Write your own plugin to override "line.separator" before the pom is updated.

Follow the Maven Guide on creating a simple plugin. All it needs to do is override value. Configure the plugin to execute in the phase prior to the pom modification.

System.getProperties().setProperty("line.separator", "\n");
  1. Build in a Linux VM.

There is an option that doesn't correct the Windows compatibility issue, but should solve your core problem. Look at creating small VirtualBox Linux server. A simple NAT connection should suffice for Internet access. Install Maven, Java, etc on this machine. Build on it. Because it's Linux the line separator should be only '\n'. The VM would need 256 - 512 MB of RAM and 20 GB of storage space (Linux + a lot of possible Maven dependencies). If you end up liking it, you could even expand it to house a continuous integration product like Jenkins.

Virmundi
  • 2,497
  • 3
  • 25
  • 34
  • Is the maven-assembly-plugin used by the maven-release-plugin? – Ralph Feb 16 '15 at 20:39
  • No, this is a new dependency for your maven project. – Virmundi Feb 16 '15 at 20:53
  • 1
    So I do not believe that this work, because Maven-Release-Plugin's `release:prepare` goal modify the pom and commit them. - Or did you see any way to hook in, so that the Maven-Assembly-Plugin correct the linebreak after Maven-Release-Plugin modifiy the code but before Maven-Release-Plugin commits it. – Ralph Feb 17 '15 at 07:35
  • If the first way doesn't work, you'll have to look at the other two options. I looked around at the code for the release [plugin][1]. They hard code the line separator. I can't find a property that overrides it. [1]: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.release/maven-release-manager/2.5.1/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#AbstractRewritePomsPhase.0ls – Virmundi Feb 17 '15 at 14:30
  • 1
    Good hint: `ReleaseUtil.LS`; is not abolute hard coded its value is taken from the System Property `public static final String LS = System.getProperty( "line.separator" );` -- so I need to find a way so set the System Property while the release plugin is executed. – Ralph Feb 17 '15 at 15:19
  • @Ralph then how about something like: maven-release-plugin->configuration->arguments->"-Dline.separator='\n'"? Might have to work to change it back for other plugins, though. – Papasmile Feb 23 '15 at 16:34
  • @Papasmile: i tryed this, but java take "\n" literally – Ralph Feb 23 '15 at 21:36
  • 1
    @Virmundi: i reward this answer because to honor you work, even if the linux/vm solutions are not a solution for me. For the maven assambly solution: I see no way how this should work. – Ralph Feb 23 '15 at 21:40
  • @Ralph ah, try '\\n'. Also try setting via a parameter ${my.lf.value.i.want}; if you do that you could load parameters eg from a file or command-line input. – Papasmile Feb 23 '15 at 21:51
  • ...related notes http://stackoverflow.com/questions/16005437/passing-arguments-to-maven-release-build – Papasmile Feb 23 '15 at 21:57
  • this won't work for pom.xml modified by release plugin. And in fact this is convoluted hard workarounds on a topic not solved like this by people working on multiple OSes: use your source control management "svn:eol-style=native" like feature – hboutemy Aug 26 '15 at 06:29
3

Working in Linux, but wanting Windows line-endings in e.g. set-versions output, this quick-fix works for me:

mvn -Dline.separator=$'\r\n' \
    -DautoVersionSubmodules=true \
    -DdevelopmentVersion=1.2.3-SNAPSHOT \
    release:update-versions
javabrett
  • 7,020
  • 4
  • 51
  • 73
3

I work on Windows (CRLF) and use LF endings in my files. I use Git.

I have chosen to set core.autocrlf to input. According to https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration input setting is for this situation:

If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input

However, it works for me well when I am on Windows. You can give it a try if your situation is similar:

  • If CRLF file gets committed to the repository, CRLF line endings will be visible on checkout. Therefore one can react (e.g. remind colleagues to pay attention to the line endings).
  • Using Maven Release Plugin will not cause pom.xml to be committed with CRLF (it will be LF).

Downside:

  • Solution is machine-dependent. One can forget verifying Git settings before releasing from a different machine, causing CRLF pom.xml to be committed.
RemekGdansk
  • 63
  • 1
  • 7
2

My workaround is to use the SVN Property: svn:eol-style=native. So SVN "convert" the pom.xml when it is updated or committed.

Ralph
  • 118,862
  • 56
  • 287
  • 383
  • and every source control managment has such a feature: that's the way everybody working with multiple teams on different OSes do – hboutemy Aug 26 '15 at 06:27