cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Bowser (JIRA)" <>
Subject [jira] [Commented] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
Date Mon, 05 Mar 2018 19:16:00 GMT


Joe Bowser commented on CB-13953:

The wrapper is in gitignore because Apache policy prevents us from committing the Gradle
Wrapper.  The reason we use wrapper.gradle is so that we can generate the wrapper.  We do
not plan on supporting any Gradle Wrapper customization, since we lack the ability to do so
due to the ASF policy on bundling gradle.

> Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in
> --------------------------------------------------------------------------------------------
>                 Key: CB-13953
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: cordova-android
>    Affects Versions: cordova-android-7.0.0
>         Environment: android build
>            Reporter: armin
>            Assignee: Joe Bowser
>            Priority: Minor
>   Original Estimate: 8h
>  Remaining Estimate: 8h
> Cordova is tightly coupled with the gradle executable and it is verifying it being on
the path even though the gradle wrapper is available. Also the JAVA_HOME has to be already
available or java be on the path before running cordova commands even though these can be
set during the build.
> In general there are several problems with the current gradle bootstrapping process:
>  * Cordova checks for gradle being on the path and fails execution if it isn't there
even though the wrapper is already generated so gradle is not needed at that point. The wrapper
files are also on .gitignore for no reason since committing them is fairly standard practice
and they could be bundled with cordova from the beginning to avoid dependency on gradle in
general and to tie the gradle version to the cordova version.
>  * In general the checks inside cordova are not sufficient to determine if a given "requirement"
is available (or will be set during the build) or not, it should be possible to continue the
build even if the build-in requirement checks fail
>  * The gradle wrapper is generated by Cordova instead of the user as it should be and
as it is the gradle convention -> this means any customization process is extremely difficult
and we have no control. It is understandable to tie the gradle version to a cordova version
but this version check should be done during execution and not before so the users can manage
their own wrapper
>  * Cordova is using a separate gradle file for generating the wrapper and not the actual
build.gradle file -> wrapper.gradle is being used for generation which means any configuration
from build.gradle is not respected, such as wrapper version or wrapper customization (for
example we also generate the JAVA_HOME variable into the wrapper so we would not need java
or gradle on the path at all after the initial install, as we only have a local installations)

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message