gradle wrapper broken

[nhhockeyplayer]

Bug Report

gradle wrapper broken

Problem

cordova platform add android cordova platform add browser gradle wrapper --gradle-version 5.1.1 cordova prepare

What is expected to happen?

app\build.gradle : line:42

task wrapper(type: Wrapper) {
    gradleVersion = '5.1.1'
}

What does actually happen?

app\build.gradle : line:42

task wrapper(type: Wrapper) {
    gradleVersion = '4.10.3'
}

Information

9.0.0 (cordova-lib@9.0.1)

Command or Code

Environment, Platform, Device

Version information

Checklist

• [x] I searched for existing GitHub issues
• [x] I updated all Cordova tooling to most recent version
• [x] I included all the necessary information above

[nhhockeyplayer]

C:\mobile>cordova --version 9.0.0 (cordova-lib@9.0.1)

mobile>gradle --version

mobile>if "Windows_NT" == "Windows_NT" setlocal

mobile>set DIRNAME=C:\gradle-5.1.1\bin\

mobile>if "C:\gradle-5.1.1\bin\" == "" set DIRNAME=.

mobile>set APP_BASE_NAME=gradle

mobile>set APP_HOME=C:\gradle-5.1.1\bin..

mobile>set DEFAULT_JVM_OPTS="-Xmx64m"

mobile>if defined JAVA_HOME goto findJavaFromJavaHome

mobile>set JAVA_HOME=C:\DEVTOOLS\SUN\jdk1.8.0_151

mobile>set JAVA_EXE=C:\DEVTOOLS\SUN\jdk1.8.0_151/bin/java.exe

mobile>if exist "C:\DEVTOOLS\SUN\jdk1.8.0_151/bin/java.exe" goto init

mobile>if not "Windows_NT" == "Windows_NT" goto win9xME_args

mobile>set CMD_LINE_ARGS=

mobile>set _SKIP=2

mobile>if "x--version" == "x" goto execute mobile>set CMD_LINE_ARGS=--version

mobile>set CLASSPATH=C:\gradle-5.1.1\bin..\lib\gradle-launcher-5.1.1.jar

mobile>"C:\DEVTOOLS\SUN\jdk1.8.0_151/bin/java.exe" "-Xmx64m" -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=tru e "-Dorg.gradle.appname=gradle" -classpath "C:\gradle-5.1.1\bin..\lib\gradle-launcher-5.1.1.jar" org.gradle.launcher.GradleMain --version

---

Gradle 5.1.1

Build time: 2019-01-10 23:05:02 UTC Revision: 3c9abb645fb83932c44e8610642393ad62116807

Kotlin DSL: 1.1.1 Kotlin: 1.3.11 Groovy: 2.5.4 Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018 JVM: 1.8.0_151 (Oracle Corporation 25.151-b12) OS: Windows 7 6.1 amd64

[nhhockeyplayer]

WELL MY PROJECT SETUP

a root proj named mobile and sub child projects android (which get instantiated when add platform)

using gradle wrapper has to apply to BOTH projects in order to get the poms right

feel free to close if you want

but the amount of work took me three days to sift thru this and get it right alot of repeated resets removes reconfigures in and out of three different ide's

not fun

[nhhockeyplayer]

The solution was to run gradle wrapper on both projects not just one

to prevent gradle-4 from taking over everything I tried to configure to gradle-5.1.1

[nhhockeyplayer]

spoke too soon

the sub project platforms/android gradle dir

properties file continues to default to gradle-4 @#!#$@$%@#

distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.3-all.zip zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists

[nhhockeyplayer]

this is happening again

it all started when android studio asked me if I would like to upgrade to the latest supported gradle-5.5.1

i said ok... since what harm could a simple build tool do and as a developer would like to stay fresh at least on the build tools its rare those revs really get under your skin nor should create too much corruption at runtime... but i caught in build hell now

in the platforms/android subdir

i deleted everything under platforms/android/.gradle directory leaving just the 5.5.1 stuff

i deleted everything beneath \users\owner.gradle (though nothing is populated to that maven repo yet)

I redo the gradle wrapper thing again

gradle wrapper --gradle-version 5.1.1

then

cordova prepare

then

cordova build

build says success... BUT

in the gradle dir the wrapper configuration... ? something is hardwired and continues to insist on gradle-4 and starts to instrument the build files again

gradle-wrappers.properties distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.3-all.zip zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists

something is forcing to the version 4 dist repo

is this normal ?

can someone suggest a normal expected outcome

im thinking if I continue to work with this configuration it will go ahead and keep trying to populate with gradle-4

[nhhockeyplayer]

this could have been done nicer rather than hardwiring ther archetype

3 days

and i find out the hidden culprit

app/build.gradle

task wrapper(type: Wrapper) { gradleVersion = '4.10.3' }

:"(

can someone delete that task and make the thing configurable like the gradle wrapper INTENDED TO

is it the task or is it the env variable or is it both or should we toss a coin or guess for three days while these two contending options are spoiling everything in the build

this could have been more defensive sorry

[breautek]

I think this might also be related to https://github.com/apache/cordova-android/issues/718

[janpio]

What is this "archetype" you are talking about? What who are you being impolite to by calling them "juniors" and further being abusive of them?

[nhhockeyplayer]

archetype is a standard meta acronym a project of projects we have a root project platform project app project the build was archetyped with gradle

i have no time to debate sorry android studio resolved everything

I had to create a lengthy automated script to regenerate everything to get past the lapses in integrity of the attempted archetype of gradle

good luck in making it tighter it shouldnt take much more your almost there

[nhhockeyplayer]

what i suggest is changing GRADLE_USER_HOME to GRADLE_HOME the USER is out of sync with norm JAVA_HOME ANT_HOME fair?

Now edit the task hardwiring the gradle revision to an environment variable or a project pom variable (ie. ${gradle-revision} ) so the poms can be updated outside beyond the gradle script sand force a refresh of maven dependencies

other than that great work for trying, its all hard work i know

[bsbechtel]

@nhhockeyplayer Could you share details on your work around so others can fix their issue until a fix is implemented?

[nhhockeyplayer]

Hi The solution for me was to back down to the revision thats hardwired in the gradle task I had no luck trying to surpass whats deployed into node_modules

app build.gradle

task wrapper(type: Wrapper) { gradleVersion = '4.10.3' }

I installed that version locally on my computer I defined GRADLE_HOME I defined GRADLE_USER_HOME

both to point to the installation

then I added both env var to my PATH

then refresh all maven dependencies and rebuild

maven repo's can become corrupt to I nuked all mine just to be safe so they could repopulate

[nhhockeyplayer]

this is my script mob.bat

im on windows, root is another batch file that changes me to my angular project which is the parent of my cordova project named mobile

im wrapping an angular project with a cordova project for playstore

echo @on

cd c: cd \ call root cd mobile

echo @off

[nhhockeyplayer]

this is my cordova script

named reset.bat

it resets and regenerates everything (maven repo's too) within the root dir of my mobile directory which is my cordova project which is a subdir of my angular project

echo @on call owner rm -rf .gradle/*

c: cd \ cd C:\Program Files\Android\Android Studio\gradle\m2repository\com\android\tools\build rm -rf gradle

call mob call cordova platform rm android call cordova platform rm browser rm -rf .gradle/*

call cordova platform add browser call cordova platform add android

cd platforms/android call gradle wrapper --gradle-version 4.10.3 call cordova prepare

cd app call gradle wrapper --gradle-version 4.10.3 call cordova prepare

call mob call gradle wrapper --gradle-version 4.10.3 call cordova prepare

call npm i

call cordova clean

call cordova compile cd platforms/android call cordova compile cd app call cordova compile

call mob

rem cd platforms/android/app rem call git checkout build.gradle

call mob

call gradlew build --refresh-dependencies cd platforms/android call gradlew build --refresh-dependencies cd app call gradlew build --refresh-dependencies call mob

phonegap serve --port 4000

echo @off

[nhhockeyplayer]

i loved maven years back but never liked transient dependencies or corrupted repo's they are hard to resolve and you have to be aware especially when your defining the preset model

be defensive

the gradle archetype artifact is not that big of a download since this is DEPENDENT within your sub archetype model force it to be refreshed or better yet reset repopulated

but anyone considering changing the gradle rev right now should be aware of what they are about to be pulled into

i dont mind taking the hit

great job

• cheers

[bsbechtel]

I actually realized you just need to change this line in /android/cordova/lib/builders/ProjectBuilder.js:

var distributionUrl = process.env['CORDOVA_ANDROID_GRADLE_DISTRIBUTION_URL'] || 'https\\://services.gradle.org/distributions/gradle-5.1.1-all.zip';

[brodybits]

I wonder if this is related to #718 or not. A minimal reproducible example would really help us confirm.

I just raised #780 to update for Gradle 5, which would be a MAJOR BREAKING update.

[nhhockeyplayer]

718 ?

well it seems obvious it would cause android studio to trip up too especially if someone starts mucking with the rev #

though android studio does a good job of making things happy until it gets tripped I already experienced that subsequent attempts to operate cordova feel iffy at best if android studio gets a clean build to fly but since I operated my script I have full control and know whats generating what prior to build

sorry Im not about to expose my project its rather large and private

best

[janpio]

sorry Im not about to expose my project its rather large and private

Which is why @brodybits didn't ask for that, but for you to create a minimal example that can reproduce the problem. The link he posted explicitly asks for a new project to be created.

[nhhockeyplayer]

with all due respect Im in transition right now and just dont have a moment to whip up a repo to demonstrate but I do think folks are over thinking this

this is simply reproducible by creating your cordova project and then attempting to operate a different gradle version namely the one android studio likes.

thats it

best

[breautek]

this is simply reproducible by creating your cordova project and then attempting to operate a different gradle version namely the one android studio likes.

I'm running Android Studio 3.4.2, which is their current latest release with Gradle 4.x without problems, so I don't think it's quite that simple.

[breautek]

Removed the help wanted label as the work is already done in PR https://github.com/apache/cordova-android/pull/792