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 <dougb...@dougborg.org> 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 <basej...@gmail.com> >> 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 adt-dev+u...@googlegroups.com. >>> 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 adt-dev+unsubscr...@googlegroups.com. > 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 adt-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
