Triple-T / gradle-play-publisher

GPP is Android's unofficial release automation Gradle Plugin. It can do anything from building, uploading, and then promoting your App Bundle or APK to publishing app listings and other metadata.
MIT License
4.13k stars 341 forks source link

"bootstrap" task appends LF (new line character) to each downloaded text file #807

Closed yvolk closed 4 years ago

yvolk commented 4 years ago

Following README.md I configured the plugin for my AndStatus app ( https://github.com/andstatus/andstatus/tree/master/app )

I executed "bootstrap" task, and see that each text file inside https://github.com/andstatus/andstatus/tree/master/app/src/main/play folder has "new line" ( 0xA ) character appended.

This commit shows configuration (without credentials that are stored separately) used for the task execution and results of this execution: https://github.com/andstatus/andstatus/commit/45e66c322e7e96800981f00dfdc9f32fba9fd490

GitHub doesn't show the ending "new line" char in UI but downloading repo zip we still see this unwanted character that potentially may cause problems...

Not a big deal to edit 100 files manually :-) but it looks like this bug (even if it is actually Google's API bug...) could be fixed in your great plugin. So far I used the bootstrap only, but result already is worth the effort :-) Thank you for the plugin!

SUPERCILEX commented 4 years ago

That's intentional: source files should always have a new line at the end. Any reason not to have it?

yvolk commented 4 years ago

I'm afraid that:

  1. My app "title" with a new line appended will look ugly. And "title" is not a "file" or "source" - it's a String, for which every character matters. Who / what will recognize this unneeded char and remove it before putting into Google Play's metadata (where it won't have any new line at the end...)?

  2. This additional character will be counted and may cause problem where maximum number of chars is limited (e.g. 80 chars for description)

  3. All text translations that I get from Crowdin don't have new line at the end. And this works good for years...

yvolk commented 4 years ago

@SUPERCILEX So this is conceptual mistake, not a programming bug. I think that files with text strings should be treated like binary files, and copied without any modifications.

SUPERCILEX commented 4 years ago

You don't have to worry about it, we automatically strip any surrounding whitespace for you. If you notice that we don't, that would be a bug.

The current implementation is working as intended and follows Git conventions.

yvolk commented 4 years ago

Ok, thanks. Will try this.