| commit | c14adc788668c050be9c7f5faf2a3c12d75b86c7 | [log] [tgz] |
|---|---|---|
| author | Yigit Boyar <yboyar@google.com> | Wed Sep 20 10:27:29 2023 -0700 |
| committer | Yigit Boyar <yboyar@google.com> | Thu Sep 28 16:59:33 2023 +0000 |
| tree | c06fc1e47287c45f5e953becf80376235e01c15f | |
| parent | 4cce02e9b2d2f165bf19f8279c333c1a0db629f8 [diff] |
Include projects with dependencies in Playground Playground builds can declare a dependency on a project using projectOrArtifact syntax intead of project, to depend on its prebuilt rather than the actual project. This was a way to keep github projects lean. Over the years, this has been a major trigger for breaking builds as it is easy for any engineer to add a dependency without thinking about the github build. Furthermore, with the gradle remote cache, we don't necessarily need it that much (still do, but a lot less). This CL significantly reduces the need for it by making github use the project dependency resolution logic (PROJECT_PREFIX) from the main build. This makes the builds more similar to the main build but comes with the disadvange of running too much stuff in CI, where we don't have good machines. It also creates a problem where the tests of commonly included projects run will multiple times for each build. To address this problem, I've created new mechanism where we distinguish between projects requested by the settings.gradle file vs projects included because they are a dependency. To do so, PlaygroundExtension passes down a parameter to the root project about the projects that are requested. Subsequently, AndroidXPlaygroundRootImplPlugin sets up the playgroundCIHostTests task to only depend on them. I've replaced a bunch of projectOrArtfiact calls with project where needed but didn't do a full cleanup. Unfortunately, we still cannot remove all of them since some cannot be built on Github. But after a cleanup (followup CL), using projectOrArtifact should be a one-off case instead of the norm (and we can probably make the playground extension do it instead of the project files). Last but not least, this CL greatly simplifies settings files for playground projects as they don't need to think about their dependencies. Current syntax is not great for this new norm so I hope to update the settings.gradle syntax in a followup CL (to make it more explicit instead of iterating over all projects). Bug: n/a Test: https://github.com/androidx/androidx/actions/runs/6280777658 Change-Id: Ida6b649f7610a20f3626e38e444e5b21f4034cc6
Jetpack is a suite of libraries, tools, and guidance to help developers write high-quality apps easier. These components help you follow best practices, free you from writing boilerplate code, and simplify complex tasks, so you can focus on the code you care about.
Jetpack comprises the androidx.* package libraries, unbundled from the platform APIs. This means that it offers backward compatibility and is updated more frequently than the Android platform, making sure you always have access to the latest and greatest versions of the Jetpack components.
Our official AARs and JARs binaries are distributed through Google Maven.
You can learn more about using it from Android Jetpack landing page.
For contributions via GitHub, see the GitHub Contribution Guide.
Note: The contributions workflow via GitHub is currently experimental - only contributions to the following projects are being accepted at this time:
When contributing to Jetpack, follow the code review etiquette.
We are not currently accepting new modules.
Head over to the onboarding docs to learn more about getting set up and the development workflow!
Our continuous integration system builds all in progress (and potentially unstable) libraries as new changes are merged. You can manually download these AARs and JARs for your experimentation.
Before uploading your first contribution, you will need setup a password and agree to the contribution agreement:
Generate a HTTPS password: https://android-review.googlesource.com/new-password
Agree to the Google Contributor Licenses Agreement: https://android-review.googlesource.com/settings/new-agreement
AndroidX uses git to store all the binary Gradle dependencies. They are stored in prebuilts/androidx/internal and prebuilts/androidx/external directories in your checkout. All the dependencies in these directories are also available from google(), or mavenCentral(). We store copies of these dependencies to have hermetic builds. You can pull in a new dependency using our importMaven tool.
