Flesh out links in gradle sync post

content/posts/improving-dependency-sync-speeds-for-your-gradle-project.md

@@ -10,7 +10,7 @@ Android developers are intimately familiar with the ritual of staring at your ID
 
 ## Obtaining a baseline
 
-To get an idea for how long it actually takes your project to fetch its dependencies and to establish a baseline to compare improvements again, we can leverage Android Studio's relatively new [Downloads Info](//d.android.com) view to see how many network requests are being made and how many of those are failing and contributing to our slower build. Gradle has a `--refresh-dependencies` flag which ignores its existing cache of downloaded dependencies and redownloads them from the remote repositories which will allow us to get consistent results, barring network and disk fluctuations.
+To get an idea for how long it actually takes your project to fetch its dependencies and to establish a baseline to compare improvements again, we can leverage Android Studio's relatively new [Downloads Info] view to see how many network requests are being made and how many of those are failing and contributing to our slower build. Gradle has a `--refresh-dependencies` flag which ignores its existing cache of downloaded dependencies and redownloads them from the remote repositories which will allow us to get consistent results, barring network and disk fluctuations.
 
 In Android Studio, create a new run configuration with a commonly used task that will require your entire dependency tree, such as `assembleDebug` and specify the `--refresh-dependencies` flag so that it looks like this:
 
@@ -22,9 +22,9 @@ When you run this task, you'll see the Build tool window at the bottom get popul
 
 ## How Gradle fetches your dependencies
 
-Gradle's dependency resolution relies on a set of user-defined repositories that are used to search for the requested dependencies, from where it will obtain the [POM](//maven) (or [Gradle Module Metadata](//gradle)) to identify the dependencies of that dependency. This keeps happening in a recursive fashion until there is a full [Directed Acyclic Graph](//wikipedia?) of dependencies where the terminal nodes are dependencies with no other child deps.
+Gradle's dependency resolution relies on a set of user-defined repositories that are used to search for the requested dependencies, from where it will obtain the [POM] or [Gradle Module Metadata] to identify the dependencies of that dependency. This keeps happening in a recursive fashion until there is a full [Directed Acyclic Graph] of dependencies where the terminal nodes are dependencies with no other child deps.
 
-Once this graph has been computed, Gradle will start downloading them as and when specific [configurations](//gradle) are requested by the build itself. For the purposes of this article, you don't need to know too much about configurations other than the fact that when you write `implementation(libs.androidx.core)` in your buildscript, `implementation` is the configuration to which you're adding the dependency specified by the `androidx-core` key in your [version catalog](//gradle).
+Once this graph has been computed, Gradle will start downloading them as and when specific [configurations] are requested by the build itself. For the purposes of this article, you don't need to know too much about configurations other than the fact that when you write `implementation(libs.androidx.core)` in your buildscript, `implementation` is the configuration to which you're adding the dependency specified by the `androidx-core` key in your [version catalog].
 
 ## A quick attempt at optimisation
 
@@ -49,7 +49,7 @@ dependencyResolutionManagement {
 }
 ```
 
-This tells Gradle that you want plugin dependencies to be looked up from \[Maven Central] and \[gMaven], and for all other dependencies to come from \[JitPack], \[gMaven], \[Maven Central], or the \[Maven Central snapshots] repository; **in that order**. This ordering is crucial, because the first
+This tells Gradle that you want plugin dependencies to be looked up from [Maven Central] and [gMaven], and for all other dependencies to come from [JitPack], [gMaven], [Maven Central], or the [Maven Central snapshots] repository; **in that order**. This ordering is crucial, because the first
 simple tweak you can make is to reorder these based on what part of your dependencies you expect to come from what repository.
 
 For example, in a typical Android build most of your plugin classpath will be dominated by the Android Gradle Plugin (AGP), so you'd want gMaven to be come first so that Gradle does not try to find it on Maven Central.
@@ -111,4 +111,14 @@ For our plugins block, we want gMaven to supply AGP and everything else can come
  }
 ```
 
-The `includeGroupsAndSubgroups` API used above is a very recent addition, so make sure you're using the current Gradle release.
+The `includeGroupsAndSubgroups` API used above is a very recent addition, so make sure you're using the current Gradle release.
+
+[downloads info]: https://developer.android.com/studio/releases/past-releases/as-giraffe-release-notes#download-info-sync
+[pom]: https://maven.apache.org/pom.html
+[gradle module metadata]: https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
+[directed acyclic graph]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
+[configurations]: https://docs.gradle.org/current/userguide/declaring_dependencies.html
+[version catalog]: https://docs.gradle.org/current/userguide/platforms.html#sub:central-declaration-of-dependencies
+[maven central]: https://repo1.maven.org/maven2/
+[gMaven]: https://maven.google.com/web/index.html
+[jitpack]: https://jitpack.io