Merge pull request #73 from lucidsoftware/update-miscellaneous-docume…

…ntation

Updated miscellaneous documentation

CONTRIBUTING.md

@@ -1,18 +1,18 @@
 # Contributing guidelines
 
-Contributions should follow the [principals](../README.md#principals) of rules_scala_annex.
+Contributions should follow the [principles](README.md#principles) of `lucidsoftware/rules_scala`.
 
 ## Documentation
 
-To generate the [Stardoc](https://github.com/bazelbuild/skydoc),
+To generate the [Stardoc](https://github.com/bazelbuild/stardoc),
 
 ```
 $ ./scripts/gen-docs.sh
 ```
 
 ## Formatting
 
-[Buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier) is used to format Skylark files,
+[Buildifier](https://github.com/bazelbuild/buildtools/blob/main/buildifier) is used to format Skylark files,
 and [Scalafmt](https://scalameta.org/scalafmt/) is used to format Scala files. To run them,
 
 ```
@@ -21,7 +21,7 @@ $ ./scripts/format.sh
 
 ## Maven deps
 
-[rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) is used to generate maven deps. If you need to change
+[rules_jvm_external](https://github.com/bazel-contrib/rules_jvm_external) is used to generate maven deps. If you need to change
 dependencies, modify `maven_install` in the following different `workspace.bzl` files
 
 ```

README.md

@@ -139,6 +139,6 @@ scala_library(
 
 ## Further Documentation
 
-See [contributing guidlines](CONTRIBUTING.md) for help on contributing to this project.
+See [contributing guidelines](CONTRIBUTING.md) for help on contributing to this project.
 
 For all rules and attributes, see the [Stardoc](docs/stardoc).

docs/newdocs/macros.md

@@ -3,7 +3,7 @@
 Using [ijar](https://github.com/bazelbuild/bazel/tree/master/third_party/ijar) poses a challenge in Scala because Scala macros are resolved during compilation. If a Scala macro references methods stripped away by ijar, things break.
 However, forgoing `ijar` use altogether is sub-optimal---using `ijar` dramatically decreases unnecessary recompilation between builds.
 
-`higherkindness/rules_scala` strives to optimally integrate `ijar` and Scala macros as follows:
+`lucidsoftware/rules_scala` strives to optimally integrate `ijar` and Scala macros as follows:
 
 1. `scala_library`, `scala_binary`, and `scala_test` have a Boolean `macro` attribute which must be set to true if the rule contains any Scala macros
 2. During the classpath resolution phase, we set `macro_classpath` to contain the transitive runtime classpaths of all `deps` for which `macro = true`
@@ -12,4 +12,4 @@ However, forgoing `ijar` use altogether is sub-optimal---using `ijar` dramatical
    * If `macro` was true, we get problematic ijars; however, this won't be an issue:
 4. During compilation, we have `macro_classpath` precede the compile classpath of the merged `JavaInfo`, forcing the compiler to use the full classes
 
-This lets us make use of ijars as much as possible, without breaking things due to Scala macro usage.
+This lets us make use of ijars as much as possible, without breaking things due to Scala macro usage.

docs/newdocs/phases.md

@@ -1,6 +1,6 @@
 ## Phases
 
-Most rules in `higherkindness/rules_scala` are architected using phases. Phases break down the Bazel Analysis stage into logical chunks.
+Most rules in `lucidsoftware/rules_scala` are architected using phases. Phases break down the Bazel Analysis stage into logical chunks.
 For example, the implementation of `scala_binary` is:
 
 ```python