[
https://issues.apache.org/jira/browse/CB-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
armin updated CB-13953:
-----------------------
Remaining Estimate: 8h (was: 24h)
Original Estimate: 8h (was: 24h)
> Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being
> set in advance
> --------------------------------------------------------------------------------------------
>
> Key: CB-13953
> URL: https://issues.apache.org/jira/browse/CB-13953
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
