[GRADLE-2614] POMs are written with the default line ending of the platform Created: 02/Jan/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

If you execute the task `uploadArchives`, it will create pom.xml files with platform default line endings. This is a problem when `uploadArchives` is used to deploy to a local directory to manually maintain a Maven repository. That is, I want to upload this repository to Github and want to use LF line endings (actually I set git to always convert line endings to LF) and this line ending conversion does not work with sha1 and md5 checksums.

Currently I use the following workaround:

afterEvaluate {
System.setProperty('line.separator', '\n');
}

I find this workaround somewhat fragile because it might not work if Gradle run tasks in separate processes.

Is it somehow possible to specify the line endings with which pom files are generated?



 Comments   
Comment by Gradle Forums [ 02/Jan/13 ]

Do you happen to know what Maven does here? Does it always use LF?

Comment by Gradle Forums [ 02/Jan/13 ]

I don't think there is anything Maven does since in Maven there is no need to generate the pom (as it naturally exists), so I think it just copies the pom.xml. I never really verified it but what I know is that it won't change LF line endings to anything else (also I doubt that it would change anything else to LF). I believe it does nothing but copies the pom.

Comment by Gradle Forums [ 02/Jan/13 ]

That's a good point. I'll raise this as an issue.

My preference for a resolution would be to always use LF when generating the POM, but we'll have to investigate the implications.

For the time being, your workaround is the best you can do.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:26:43 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.