[jira] [Commented] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
[ https://issues.apache.org/jira/browse/CB-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387492#comment-16387492 ] armin commented on CB-13953: [~bowserj], you do not need to commit in the wrapper, you can allow the cordova users to do it (optionally) so we are not forced to have gradle available on the path on every machine (including automated environments) and rely on the built-in configuration. This is about 5 lines of code to fix for the ability to drop an unnecessary dependency and allow users to customize wrapper generation, I really do not understand the quick decision to close the ticket. > 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
[jira] [Updated] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
[ 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
[jira] [Created] (CB-13953) Cordova has a hard dependency on Gradle being on the path and JAVA_HOME being set in advance
armin created CB-13953: -- Summary: 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 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
