WAI
Status Update
No update yet.
Comments
uc...@google.com
je...@google.com
Android Studio comes with its own version of the gradle plugin in a private repository that is not accessible when building from the command line.
when building from the command line, it will try to download the version and in your case, it failed to do so (no internet access ?)
when building from the command line, it will try to download the version and in your case, it failed to do so (no internet access ?)
mm...@commonsware.com
No, it does not try to download the version. Gradle cannot find it, because the plugin is no longer in JCenter, and google() was removed:
* What went wrong:
A problem occurred configuring root project 'MyApplication'.
> Could not resolve all files for configuration ':classpath'.
> Could not find com.android.tools.build:gradle:3.0.0.
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/build/gradle/3.0.0/gradle-3.0.0.pom
https://jcenter.bintray.com/com/android/tools/build/gradle/3.0.0/gradle-3.0.0.jar
Required by:
project :
Hence, builds from Android Studio are different than builds from the command line, which runs counter to the stated objective for using Gradle in the first place.
* What went wrong:
A problem occurred configuring root project 'MyApplication'.
> Could not resolve all files for configuration ':classpath'.
> Could not find com.android.tools.build:gradle:3.0.0.
Searched in the following locations:
Required by:
project :
Hence, builds from Android Studio are different than builds from the command line, which runs counter to the stated objective for using Gradle in the first place.
xa...@google.com
Studio injects a new repo. it does not replace the google() (or any other) repo. This is working as intended. it doesn't mean it's a good experience but it is what it is.
So, yes builds are different between Studio and Gradle and we're aware of the issue. You can disable the offline repo injection in the preferences, and we're likely to make this the default in the near future, except when you create a project, so that the first open/sync doesn't fail (due to network access or lack thereof) as the lack of general IDE UI would render the experience bad in case of errors.
So, yes builds are different between Studio and Gradle and we're aware of the issue. You can disable the offline repo injection in the preferences, and we're likely to make this the default in the near future, except when you create a project, so that the first open/sync doesn't fail (due to network access or lack thereof) as the lack of general IDE UI would render the experience bad in case of errors.
wi...@xandar.com.au
The whole point of separating your build config from the IDE is so that the project can be built regardless of environment.
Having a hidden repo injected by Android Studio is just going to make the ecosystem less stable.
There is nothing wrong with new project creation failing because it is unable to download a build tool, as long as it clearly indicates that it has failed for that reason. It only happens once after which the plugin is cached.
Having a hidden repo injected by Android Studio is just going to make the ecosystem less stable.
There is nothing wrong with new project creation failing because it is unable to download a build tool, as long as it clearly indicates that it has failed for that reason. It only happens once after which the plugin is cached.
mm...@commonsware.com
> You can disable the offline repo injection in the preferences
Searching Android Studio 3.0 Settings for "repo", "google", "maven", "plugin", "offline", or "inject" does not turn up anything that would seem to match what you describe here. Where is this option?
> except when you create a project, so that the first open/sync doesn't fail (due to network access or lack thereof) as the lack of general IDE UI would render the experience bad in case of errors.
I am all for improving the out-of-the-box experience for new users, particularly those in connectivity-challenged areas.
On macOS and Linux, your first run of Android Studio after installation requires that you be online, because otherwise the new-installation wizard cannot download required components. I'm not a Windows guy, so I don't know if Android Studio somehow behaves differently there, though the file sizes of the downloads suggests that it should behave the same. If they have connectivity at this point, they probably have connectivity when they create their first project.
Plus, all you do by having the plugin available in an injected repo is kick the can down the road for two seconds. If the user is offline (and could not download the plugin), they will fail when the build reaches the project dependencies, because they cannot download any of those dependencies, and every template depends on at least JUnit and ConstraintLayout (and frequently much more). If your hidden injected repo has *those* too... that's worse than I had been anticipating.
Off the cuff, I think that this could be addressed by populating the standard Gradle artifact cache. If we need Internet access on first-run anyway for the new-installation wizard, as part of that processing, execute a task in your own Gradle file that happens to use the Android Plugin for Gradle and happens to have a dependencies {} list that is the superset of all the dependencies used in all of the templates. Now, if the rest of Android Studio is working properly, the user should be able to enter offline mode, as all of the requisite pieces would be cached for whatever template they try to use. You avoid a hidden injected repo, external builds (e.g., command line) behave normally, etc.
If you're trying to get away from needing connectivity even for that first Android Studio run (i.e., you'll start packaging more stuff in the initial download), then perhaps the Gradle Tooling API has an option for pre-caching artifacts, or could have such an option added to it.
I'm happy to brainstorm further on how to solve the problem, if that's of any value to you. If you're convinced that your hidden-repo approach is what you want to use, I humbly suggest that somebody write an Android Developers Blog post explaining what's going on.
Searching Android Studio 3.0 Settings for "repo", "google", "maven", "plugin", "offline", or "inject" does not turn up anything that would seem to match what you describe here. Where is this option?
> except when you create a project, so that the first open/sync doesn't fail (due to network access or lack thereof) as the lack of general IDE UI would render the experience bad in case of errors.
I am all for improving the out-of-the-box experience for new users, particularly those in connectivity-challenged areas.
On macOS and Linux, your first run of Android Studio after installation requires that you be online, because otherwise the new-installation wizard cannot download required components. I'm not a Windows guy, so I don't know if Android Studio somehow behaves differently there, though the file sizes of the downloads suggests that it should behave the same. If they have connectivity at this point, they probably have connectivity when they create their first project.
Plus, all you do by having the plugin available in an injected repo is kick the can down the road for two seconds. If the user is offline (and could not download the plugin), they will fail when the build reaches the project dependencies, because they cannot download any of those dependencies, and every template depends on at least JUnit and ConstraintLayout (and frequently much more). If your hidden injected repo has *those* too... that's worse than I had been anticipating.
Off the cuff, I think that this could be addressed by populating the standard Gradle artifact cache. If we need Internet access on first-run anyway for the new-installation wizard, as part of that processing, execute a task in your own Gradle file that happens to use the Android Plugin for Gradle and happens to have a dependencies {} list that is the superset of all the dependencies used in all of the templates. Now, if the rest of Android Studio is working properly, the user should be able to enter offline mode, as all of the requisite pieces would be cached for whatever template they try to use. You avoid a hidden injected repo, external builds (e.g., command line) behave normally, etc.
If you're trying to get away from needing connectivity even for that first Android Studio run (i.e., you'll start packaging more stuff in the initial download), then perhaps the Gradle Tooling API has an option for pre-caching artifacts, or could have such an option added to it.
I'm happy to brainstorm further on how to solve the problem, if that's of any value to you. If you're convinced that your hidden-repo approach is what you want to use, I humbly suggest that somebody write an Android Developers Blog post explaining what's going on.
xa...@google.com
#5 we guarantee that the bundled repo contains the same artifacts as the ones you find on the external repos. Because they are versioned, it's really just the same as having a local mirror.
Mark, go to preferences under Build > Gradle > Android Studio there's a "Disable embedded maven repository"
I agree that nowadays we require more stuff to be installed, though we used to have a Windows installer with a prepackaged SDK. I think we don't have this anymore, so this is less useful. We've been talking about not enabling it by default anymore. we can certainly revisit this.
One other issue though is that we are lacking support for good download progress when gradle does the download so we've been trying to mitigate that problem too. Having gradle download dependencies (and itself) during import with no feedback, on a slow connection is a terrible experience. Even if you inject the repo just for the first build, and then run a build where it download things, this is a much better experience as Gradle's console output does show some progress.
"Off the cuff, I think that this could be addressed by populating the standard Gradle artifact cache" that's not possible at the moment, but it's definitively a better solution. We've working on fixing performance and scalability first so this kind of stuff has had to been down prioritize unfortunately.
Mark, go to preferences under Build > Gradle > Android Studio there's a "Disable embedded maven repository"
I agree that nowadays we require more stuff to be installed, though we used to have a Windows installer with a prepackaged SDK. I think we don't have this anymore, so this is less useful. We've been talking about not enabling it by default anymore. we can certainly revisit this.
One other issue though is that we are lacking support for good download progress when gradle does the download so we've been trying to mitigate that problem too. Having gradle download dependencies (and itself) during import with no feedback, on a slow connection is a terrible experience. Even if you inject the repo just for the first build, and then run a build where it download things, this is a much better experience as Gradle's console output does show some progress.
"Off the cuff, I think that this could be addressed by populating the standard Gradle artifact cache" that's not possible at the moment, but it's definitively a better solution. We've working on fixing performance and scalability first so this kind of stuff has had to been down prioritize unfortunately.
mm...@commonsware.com
> go to preferences under Build > Gradle > Android Studio there's a "Disable embedded maven repository"
OK, I see that. Oddly, it does not show up when you search Settings for "maven". I had assumed that IDEA searched based on the text in the Settings screens. If there's some separate search index that your team has to maintain, then that seems to be missing this text. If it helps, I can file a separate bug report for that.
Regarding the rest, I completely understand where you're coming from. This sort of build system change is just disconcerting, particularly when I'm not sure how any of us would know that this is going on or its ramifications. For example, if a project is set up to pull the plugin from a private repo (e.g., enterprise tools server), but the embedded Maven repository is enabled... which one wins?
One possibility to help raise awareness would be to have a notification when some dependency request was fulfilled by the embedded Maven repo, assuming that google() or other repos are checked first and so the embedded one is a fallback. That would allow the offline behavior to work, but not have it be as hidden. BTW, by "notification", I am referring to the Growl-ish popups that appear in the lower-right for available updates, etc. I'm not sure what the official term is for those in IDEAland...
OK, I see that. Oddly, it does not show up when you search Settings for "maven". I had assumed that IDEA searched based on the text in the Settings screens. If there's some separate search index that your team has to maintain, then that seems to be missing this text. If it helps, I can file a separate bug report for that.
Regarding the rest, I completely understand where you're coming from. This sort of build system change is just disconcerting, particularly when I'm not sure how any of us would know that this is going on or its ramifications. For example, if a project is set up to pull the plugin from a private repo (e.g., enterprise tools server), but the embedded Maven repository is enabled... which one wins?
One possibility to help raise awareness would be to have a notification when some dependency request was fulfilled by the embedded Maven repo, assuming that google() or other repos are checked first and so the embedded one is a fallback. That would allow the offline behavior to work, but not have it be as hidden. BTW, by "notification", I am referring to the Growl-ish popups that appear in the lower-right for available updates, etc. I'm not sure what the official term is for those in IDEAland...
Description
Android Plugin Version: 3.0.0
Module Compile Sdk Version: n/a
Module Build Tools Version: n/a
Android SDK Tools version: 27
Steps to Reproduce:
1. Create a new project in Android Studio 3.0, accepting all defaults
2. Build the project in Android Studio, and note that it builds
3. From the command line, build the app module, and note that it builds
4. Remove the google() line from the repositories closure in the buildscript closure, so you wind up with something like this:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.0.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
5. Clean and build the project in Android Studio, and note that it builds
6. From the command line, build the app module
Expected Results: the module to build, since it built in Android Studio
Actual Results: build failure, because Gradle cannot find com.android.tools.build:gradle:3.0.0
The error makes sense... except that it does not happen in Android Studio builds. The point behind using Gradle in Android Studio was so that we could get the same builds from inside Android Studio as from outside Android Studio, and that's not happening.