Hey Xavier, I invited Doug Borg to comment on this thread as he is part of the team responsible for maintaining ReadyTalk's (my company's) gradle wrapper. I have an admittedly limited understanding of what all is happening behind the scenes, as sbarta pointed out the wrapper can be a black box that just does things. As such his word should be taken over mine, and I think the confusion here is largely due to a different definition of the gradle wrapper.
I will change my setup to "Use default Gradle wrapper" as we have defined our gradle wrapper in the properties file: wrapperUrl=https\://<artifact host>/.../readytalk-gradlew-1.2.0-2.2.1-bin.zip However the problem still persists, to reproduce: 1. Open preferences, go to gradle, set "Use default Gradle wrapper" 2. Background tasks indicates a "Refresh of project occurs", which completes successfully 3. At this point the project is fully functional, I can build, deploy to devices, and work as normal 4. Click the "Sync project with gradle files" button, or alternatively make a change to a build.gradle file which gives the yellow "Gradle files have changed... " with a Sync Now link 5. Either one of these actions resets my setup to "Use local gradle distribution", which results in a broken build as gradle cannot find the buildscript dependencies I am happy to provide more information if needed. Sorry about all the confusion. On Wednesday, December 3, 2014 6:42:08 PM UTC-5, Xavier Ducrohet wrote: > > My original response was due to a typical misunderstanding of how the > wrapper works in Studio. > > What you say though is correct: custom distribution, tied with the usage > of the wrapper is perfectly valid. By "usage of the wrapper", I mean having > gradle/wrapper/gradle-wrapper.properties that point to your custom > distribution of Gradle. This should still be working. > > The OP said "My company has a standard gradle wrapper that does a variety > of things". I don't understand what this means. The Wrapper's role is to > read that property file and tell gradlew where the distribution of Gradle > to use is. The wrapper doesn't add tasks, or anything. > > So I'm still a bit confused what the OP's actual setup is. > > Now talking with Alex, the option in IntelliJ/Studio to "use customizable > gradle wrapper" is also somewhat weird and possibly (well definitively, > based on this thread) broken. It uses reflection on the Gradle tooling > api, and uses internal Gradle APIs, so this is really not something we want > to use. We're going to remove it from Studio. > > Your options should really be: > - use a local Gradle install. > - or, use the version of Gradle declared in the wrapper properties file. > This is the "Use default Gradle wrapper" option and should work for you, > whether you use a standard Gradle distribution or a custom one. > > 2 points remain: > - If you use a custom gradlew to pass --init-script, don't do this. I > don't think that's what OP does (which is what I thought at first), because > this never worked. If you want to do this, you need a custom Gradle > distribution instead (since putting it in ~/.gradle won't work for teams). > > - There is a small issue in up to RC2. > We started shipping the RC with a bundled version of Gradle. This is to > improve the first out of the box experience where developers 1. launch > studio 2. create a project 3. open it. The #3 step would sync the project > and download Gradle + plugins which could take a while. So we bundle them > and at sync time, detect that the wrapper properties file points to a > standard gradle and replace it with the local version bundled inside > Studio. This is the path you see in the screenshot attached in the OP. The > result should be the same, and it should only happen if we detect a version > of Gradle that is the standard one, and which version match the embedded > one. > In RC3 we will detect if you already have that version installed in your > cache already and just use that normally. However, this should not impact > you if you are pointing to a custom distribution of Gradle, so something > else might be a problem if that's the case. > > I would still very much like to understand what the OP meant when he said > "customized gradle wrapper" so that we can get to the bottom of this. > > thanks > Xav. > > On Wed, Dec 3, 2014 at 1:14 PM, Doug Borg <[email protected] > <javascript:>> wrote: > >> It is definitely not odd to do these sorts of things via the Gradle >> wrapper. See: >> http://www.gradle.org/docs/current/userguide/init_scripts.html >> >> ... >> >> - >> >> Put a file that ends with .gradle in the *GRADLE_HOME*/init.d/ directory, >> in the Gradle distribution. This allows you to package up a custom Gradle >> distribution containing some custom build logic and plugins. You can >> combine this with the Gradle wrapper >> <http://www.gradle.org/docs/current/userguide/gradle_wrapper.html> as >> a way to make custom logic available to all builds in your enterprise. >> >> We have done this for years at ReadyTalk and were encouraged to do so by >> Gradleware themselves. >> >> The current behavior in Android Studio breaks one of the major enterprise >> features of Gradle. Please consider reverting back to the expected behavior >> / default behavior as seen / used in IntelliJ IDEA. >> >> It seems odd to do this sort of thing from the Gradle wrapper, since >>> ideally the wrapper ought to be an optional optimization but not required: >>> if you're building from the command line you should be able to bypass the >>> wrapper and run from a locally installed version of Gradle. >>> >> >> You misunderstand the purpose of the Gradle Wrapper. It is not really an >> "optional optimization", it is the only way to control the build >> environment your build runs in. Running a build with a different version of >> Gradle than what is defined in the wrapper can break your build, sometimes >> in sometimes subtle, sometimes not-so-subtle ways due to changes in >> packaged plugins or interfaces/ behaviors plugins may use (especially >> incubating features). >> >> >>> It also makes it harder to understand what's going on in the build >>> because it's not obvious to someone unfamiliar with the environment where >>> these extra build pieces are coming from since the wrapper is hidden. >>> >> >> That depends wholly on your context. In a company setting, there is no >> better way to setup / bootstrap private repository settings, custom build >> logic, etc. than by putting those features into a custom wrapper / >> distribution. >> >> >>> >>> What you're doing sounds like something that would be more suitable for >>> using a boilerplate external script (see http://www.gradle.org/ >>> docs/current/userguide/tutorial_this_and_that.html) >>> >> >> We set up similar initialization scripts through the wrapper. Again, see >> the quote from >> http://www.gradle.org/docs/current/userguide/init_scripts.html above. >> >> >>> >>> On Wed, Dec 3, 2014 at 11:44 AM, Pete Winterscheidt <[email protected]> >>> wrote: >>> >>>> >>>> <https://lh6.googleusercontent.com/-nDZrIFDeCCU/VH9l7yZvhaI/AAAAAAABJmc/THMD6k3DeV4/s1600/Screen%2BShot%2B2014-12-03%2Bat%2B2.33.37%2BPM.png> >>>> My company has a standard gradle wrapper that does a variety of things: >>>> adds utility tasks, sets up our local artifactory repository, and such. >>>> >>>> Without using my local gradle wrapper none of my dependencies will >>>> load, artifacts are not published. >>>> >>>> This has certainly changed from 0.9 to 1.0 as previously when I >>>> selected "Use customizable gradle wrapper" it would stay selected across >>>> gradle syncs. Now every time I do a gradle sync it resets to use local >>>> gradle distribution and breaks my build. >>>> >>>> >>>> On Wednesday, December 3, 2014 11:18:26 AM UTC-5, Pete Winterscheidt >>>> wrote: >>>>> >>>>> Hello all, >>>>> I am running a customized gradle wrapper, and Android Studio keeps >>>>> trying to ignore it. >>>>> Since upgrading to the new 1.0 RC 2 every time I do a gradle sync I >>>>> have to go to the preferences to reset the configuration to indicate that >>>>> I >>>>> am using a customized wrapper. >>>>> >>>>> Is there something I can set in a config to prevent this from >>>>> happening? >>>>> Thanks, >>>>> Pete >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "adt-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "adt-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Xavier Ducrohet > Android SDK Tech Lead > Google Inc. > http://developer.android.com | http://tools.android.com > > Please do not send me questions directly. Thanks! > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
