Tool to generate a gradle-specified repository for Android and Java dependencies.
This script creates a temporary build directory, where it will, for each of the dependencies specified in
build.gradle, take care of the following:
depsentry in DEPS.
It will then compare the build directory with your current workspace, and print the differences (i.e. new/updated/deleted packages names).
Full steps to add a new third party library or update existing libraries:
build.gradle with the new dependency or the new versions.
fetch_all.py to update your current workspace with the changes. This will update, among other things, your top-level DEPS file.
git add all the 3pp related changes and create a CL for review. Keep the 3pp/ and .gradle changes in the CL and revert the other files. The other files will be committed in a follow up CL.
Land the first CL in step 3 and wait for the corresponding 3pp packager to create the new CIPD packages. The 3pp packager runs every 6 hours. You can see the latest runs here. See
//docs/cipd_and_3pp.md for how it works.
If your follow up cl takes more than a day please revert the original cl. The bot runs 4 times a day and once it uploads to cipd there is no need to keep the modified 3pp files. When you are ready to land the follow up cl, you can land everything together since the cipd packages have already been uploaded.
fetch_all.py again. There should not be any 3pp related changes. Create a commit.
If the CL is doing more than upgrading existing packages or adding packages from the same source and license (e.g. gms) follow
//docs/adding_to_third_party.md for the review.
If you are updating any of the gms dependencies, please ensure that the license file that they use, explained in the README.chromium is up-to-date with the one on android's website, last updated date is at the bottom.
The script invokes a Gradle plugin to leverage its dependency resolution features. An alternative way to implement it is to mix gradle to purely fetch dependencies and their pom.xml files, and use Python to process and generate the files. This approach was not as successful, as some information about the dependencies does not seem to be available purely from the POM file, which resulted in expecting dependencies that gradle considered unnecessary.