First I have to say thank you so much that OpenFL now using Gradle instead of Ant.
Now, how do I use Offline Gradle distribution to compile Android target?
I have Gradle installed already on my PC, and I don’t want to redownload every time I run the command.
I thought that Gradle cached things after downloading the first time, but perhaps I am mistaken.
I would happy to help include improvements to this
I’m not fully familiar with ways to improve how we’re using Gradle
Yes, Gradle cached dependencies after the first project compilation, so whenever new projects are using the same dependencies it won’t redownload again.
I already build native Android apps using Gradle so it has the dependencies, so redownloading Gradle I think is unnecessary.
Gradle installation should ideally be registered into GRADLE_USER_HOME (as of mentioned in their official docs) . That way several IDEs like Intellij would recognize that.
In openfl build, when I open up “bin” folder in android export folder, I found that OpenFL uses Wrapper mechanism and that is
however , we can actually uses local distribution file just like this on Windows:
Windows: distributionUrl=file:/d:/gradle-2.10-bin.zip
On Linux it must be something like : distributionUrl=file:/tmp/gradle-2.10-bin.zip
In OpenFL , we have “openfl setup android”.
Previously when OpenFL uses Ant, it will also ask to download Ant or link Ant installation.
Now, why don’t we use this mechanism for Gradle and pass that value to distributionUrl=file:/[path_to_gradle_offline.zip] so we can use local distribution and save time (and bandwith :p)
I hope this should be there in the next OpenFL release, this would be HUGE and truly MATURE transition from Ant to Gradle.
Thank you
Something wrong happens if wrapper redownloading gradle every time.
In my case (macOS) wrapper cache gradle dists in ~/.gradle/wrapper/dists
I can confirm that it’s the same on Windows.
Do you guys think we should bundle Gradle with Lime, so it works offline?
No.
The Gradle wrapper should only download Gradle once, and after that it’ll work offline. Whatever’s going on here is a problem with Djancoeg’s setup, not Lime.
This answer suggests it might be because the gradle-wrapper.jar file is out of date. However, I’m skeptical about that, because I’m using the same JAR file without any trouble.
Djancoeg, please check the folder that Restorer and I mentioned. Do you see lots of copies of Gradle? One? None?
If you see lots, then there’s something wrong with the download process. Possibly the hash function, as suggested in the Stack Overflow answer. In that case, try re-downloading Lime to make sure you have the correct copy of gradle-wrapper.jar.
If you see none, then there’s some kind of permissions problem, or some cleanup program is deleting Gradle between builds.
Yes
in the wrapper/dists folder I found several gradle versions and for me that’s fine since I’ve worked with Native Android Project that indeed require different wrapper version.
For clarification I have NO errors compiling OpenFL for Android target, I see gradle-2.10-bin there in wrapper/dists.
Currently I am working on several projects that require wrapper v2.2.1 and v2.13 and of course I’ve the distribution already
What I want is, rather than give us fixed version of wrapper,
can you guys manage to add more flexibility to let us use offline version as long as it is equal or greater than the minimum version required by lime/openfl?
So… you have exactly one copy of gradle-2.10-bin, but it downloads gradle-2.10-bin again each time you compile? Where is it putting all those copies?
Check the “last modified” timestamps, and see if it’s overwriting it.
This is why we have templates. Make a gradle-wrapper.properties file that fits your needs, put it somewhere in your project, and then add this tag:
<template path="path/to/gradle-wrapper.properties" rename="gradle/wrapper/gradle-wrapper.properties" />
I have NO problem with the default Gradle version that Lime includes and set in the default library config…Like I said, that, my project built and ran correctly.
I am currently doing an experiment to use other Gradle version that already in my PC. That is, version that differs from what Lime defined.
Well, template overriding helped only for recognizing the offline Gradle distribution.
For instance, when I create custom template and points Gradle 3.1 to distributionUrl , then rebuild I got:
Gradle version 2.10 is required. Current version is 3.1. …
I found:
context.ANDROID_GRADLE_VERSION = project.config.getString ("android.gradle-version", "2.10");
in AnrdroidPlatform.hx inside Lime lib installation.
and of course there is only one gradle-wrapper.jar that specific to v2.10?
I tried to replace wrapper that match v3.1 , and change the version to 3.1 but no luck.
I know , it seems bit contrary to what gradle wrapper suppose to.
However , I think you guys could add more flexibility.
So, you want to use gradle 3.1 instead of 2.10, and trying to point gradle wrapper to local gradle dist?
Why just not to override ANDROID_GRADLE_VERSION ? Something like that in project.xml:
<android gradle-version="3.10" />
?
Another question is why you want to use different gradle version for OpenFL project?
I can’t believe I forgot about that. I was the one who implemented it in the first place!
I think OpenFL lacks full documentation about project.xml (http://www.openfl.org/learn/docs/command-line-tools/project-files/xml-format/ is incomplete)
Thank you so much guys for your patience.
Honestly , I am new to Haxe/OpenFL world (I have just started 3 days ago 
) .
My previous experience that close to it was Flash Platform.
So I give it a try and compare between Native Andd Dev VS Flash VS OpenFL
well , I added
<android gradle-version="3.10" />
to project.xml and still the compilation return
Gradle version 2.10 is required. Current version is 3.1. …
No luck guys
Why you need gradle 3.1 ? Something bad with 2.x ?
Not bad , however , according to Gradle note release there are major changes in v3.x , for instance faster execution time (and in my experience: yes it is faster )
BUT for me in OpenFL context it doesn’t matter using v2.10 as long as the project compiled successfully
3 days ago, I got everything Haxe/OpenFL/Lime from friend, it was Lime v2.5.0 still using Ant. As I got curious I then updated everything to the latest.
My point is whether or not OpenFL/Lime support “pre-installed” Gradle build tool just like when it uses Ant.
Overriding gradle-wrapper does the job to use local Gradle dist, but when Gradle starting to download the android dependency plugins , it is fail
So for now using default version bundled by Lime template is the only working and practical solution.
Thank you
It turns out that this was my fault. Sorry! Here’s a pull request that ought to fix it:
Edit: merged!
Are there any downsides to updating our default version? Are there any clear benefits?
Well this is embarrassing. Turns out my last pull request broke Android builds. Fortunately, Joshua merged my fix as I was typing up this post.
The thing is, the version number 2.10 applies to Gradle itself, whereas the number 2.1.0 applies to the Android plugin for Gradle. The plugin attempts to choose a version number that looks a lot like Gradle’s number, but I still have no excuse for confusing the two.
@Programmer_Djancoeg It’s unclear if the Android plugin supports Gradle 3.3 yet. The site only lists plugin versions up to 2.1.3 and Gradle versions up to 2.14.1. However, as seen here, they’ve released new plugin versions since then.
Yeah,…me too. Since Gradle is not exclusive to Android, it is not only about Gradle but also Google as major Android backer.
Anyway , thanks alot guys for your hard work.