search

onyxbits / raccoon4

APK Downloader for Google Play
https://raccoon.onyxbits.de
Apache License 2.0
644 stars 90 forks source link

Gradle build changes: version upgrades for gradle, plugins and dependencies #93

Closed dejan2609 closed 3 years ago

dejan2609 commented 3 years ago

Details:

dejan2609 commented 3 years ago

Note: force-pushed in order to solve build.gradle file "No newline at the end of file" issues.

onyxbits commented 3 years ago

Does this solve a particular problem or is it just being about up to date?

jpstotz commented 3 years ago

@onyxbits The updated edu.sc.seis.launch4j plugin now uses new most recent Launch4j version which fixes a few bugs for finding an installed JRE/JDK. Not sure if this was a problem with raccoon users.

onyxbits commented 3 years ago

Next time test this properly! This just cost me an hour to revert because

Do NOT up lib versions simply because there's a new release of something available. In particular do NOT send pull requests without explaining why a new version of lib xyz is needed.

dejan2609 commented 3 years ago

Next time test this properly!

Mea culpa @onyxbits !

Pardon me for asking (and I am not being sarcastic here): how can we execute tests in a proper way ? Thing is that ./gradlew clean test returns inconclusive results (at least in my case, see attached snapshots: gradle tests execution stuck on 87% on both Windows and Linux). I guess I should created draft PR instead and then clarify with you why tests are inconclusive, but it is what it is. I had a good run with 2 previous commits being successful, but all good things come to an end.

Assumable I should that generate .exe binary, start it and download some apk; and, no I didn't do that (guilty as charged).

Speaking of testing: what do you think about adding CI server test executions for push requests ? I would be interested to help with that: https://github.com/features/actions Let me know if you interested, I have a rich experience with CI/CD.

Do NOT up lib versions simply because there's a new release of something available. In particular do NOT send pull requests without explaining why a new version of lib xyz is needed.

As per your comment above: https://github.com/onyxbits/raccoon4/pull/93#issuecomment-834723828 this is just an upgrade for a sake of upgrade, nothing more and nothing less.

* The HSQL update uses a new class version which is incompatible with the project

Correct. Thing is that HSQL release notes are hosted on their site and code is on SourceForge. Now I realize that I should bump HSQL version to a 2.5.2 and not to 2.6.0.

Version 2.6.0

20th Anniversary Release

March 2021. Version 2.6.0 of HyperSQL database management system adds support for Java module system and enhancements in many areas. Zip package at the download link above contains Java 11 and 8 jars. Individual jars for Java 6, 8 and 11 are available at http://hsqldb.org/download. Jars are also available at Maven repositories as version 2.6.0 for Java 11 and version 2.5.2 for Java 8.
* Something (couldn't figure out what exactly) resulted in the JAR file not getting a Main-class set

Maybe is due to a gradle plugin upgrade; breaking changes are not mentioned, so I will have to dig deeper (just by the looks of it it seems that only thing needs to be changed after bumping to 2.5.0 is this line: jar = "lib/${project.tasks.fatJar.archiveName}"

One more thing: I am not bashing gradle-launch4j creator here.... I should checked this git diff before I decided to bump this plugin version.

So there you have it @onyxbits... As I stated above I could try to help with CI server test execution for PRs and I hope you will accept my extended hand.

Test snapshots (as mentioned above):

01_tests_on_Linux

02_tests_on_Windows

onyxbits commented 3 years ago

@dejan2609

First of all: sorry for snapping at you. I was in a hurry, carelessly merged the PR and then got pissed because stuff broke and I didn't have the time for that. So, partly my fault.

Pardon me for asking (and I am not being sarcastic here): how can we execute tests in a proper way ? [..] Assumable I should that generate .exe binary, start it and download some apk; and, no I didn't do that (guilty as charged).

The master branch must always build, so yes, creating the binary would have been the minimal test to do here.

Speaking of testing: what do you think about adding CI server test executions for push requests ? I would be interested to help with that: https://github.com/features/actions

I'm quite interested in adding this, though in its current state, the source is too tightly coupled with the UI to make this meaningful.

Maybe is due to a gradle plugin upgrade; breaking changes are not mentioned, so I will have to dig deeper

Let's just leave it at the current version. It works and there are no security concerns at this point.

dejan2609 commented 3 years ago

@onyxbits I agree, from a build POV there are no reasons to force any changes at the moment.

At some point of time (and only after gradle-launch4j plugin gets Gradle version 7 upgrade) I could create some draft PR... but lets leave that to the future.