By "user-defined Gradle files" I meant what someone can put into build-extras.gradle. By supporting user-editable build-extras.gradle in the generated Android project we encounter some possible issues such as: * supporting project structure change, where we already encountered <https://github.com/apache/cordova-android/issues/552> * user needs to install cordova-android update * user needs to regenerate platforms/android for any reason
I hope we can find a better solution somehow. I was wondering if we should consider getting some of these enhancements into Cordova 9 or not. I would not personally favor holding up Cordova 9 for this kind of enhancement. I would also favor opening an issue on GitHub where we can discuss and track this item more easily, leaving it up to you. I think you are right not to open a WIP PR until you have enough confidence for possible feedback & discussion. You *could* publish an informal WIP branch if you like. I am personally not a super Gradle expert so I would probably just give feedback on quality of structure, "how it looks", etc. Thanks for your efforts on this. On Tue, Dec 4, 2018 at 12:54 PM Darryl Pogue <dvpdin...@gmail.com> wrote: > > I'm experimenting with refactoring the way Cordova's gradle files are > set up. Partly to resolve issues around the availability of Cordova > helper methods[1], the new app bundles features[2], Kotlin support[3], > and to investigate options for making the setting of build-time > variables (like min SDK versions) more consistent.[4] > > What I can tell you from my initial skimming of the code on Sunday is > that a lot of the plugin handling is done in a way that tried to > preserve as much as possible from the existing Ant-based project > structure, such as reading from project.properties files and building > up references to inject into the build.gradle file from those. > > I'm not sure what you mean by "it should be possible for user-defined > Gradle files to be configured outside the generated cordova-android > project". Plugins can provide their own gradle files to add things > like libraries and override ext variables, but those need to get > included in the app project's build because the plugin source files > themselves are included in the app project's build. > > I can try to open a WIP PR for the gradle refactoring I'm doing, but > currently it doesn't work and I'm a bit worried that it's going to end > up held up forever in review with a bunch of requested changes to > stuff that doesn't even work yet. > I'm not making changes to the existing gradle files, I'm literally > deleting them all and rewriting them to try to make them adhere better > to gradle conventions, and it's an experiment that might totally > backfire. > > [1] https://github.com/apache/cordova-android/pull/438#discussion_r216195552 > [2] https://github.com/apache/cordova-android/issues/596 > [3] https://github.com/apache/cordova-android/pull/441 > [4] https://github.com/apache/cordova-android/issues/508 > > On Tue, Dec 4, 2018 at 9:15 AM Chris Brody <chris.br...@gmail.com> wrote: > > > > I think it should be possible for user-defined Gradle files to be > > configured outside the generated cordova-android project to avoid > > issues we have encountered such as changing project structure and > > cordova-android upgrades. While it would be possible for a user to > > make a custom plugin with a custom Gradle file this may not be > > convenient for all Cordova Android apps. > > > > And it would be ideal if we could somehow alleviate the need for > > PLUGIN GRADLE EXTENSIONS START / PLUGIN GRADLE EXTENSIONS END > > placeholder comments as discussed in > > <https://github.com/apache/cordova-android/pull/568>. Maybe we could > > move the plugin Gradle extensions into a separate file? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
