[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 { 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:
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. |