With this change the stable ProGuard branch remains stable, independent
of changes in ProGuardCORE. This avoids the stable branch of ProGuard
failing if breaking changes are pushed to ProGuardCORE master branch.
* Document persisting the composite build layout using `gradle.properties`
* Speed up the build with not-very-experimental options
- Parallel project execution
- This reduces `clean assemble` by 50%
- Local build cache
- This reduces a no-op `clean assemble` by a further 60%
- File system watching
- This will be enabled by default in Gradle 7, and speeds up builds using
the same daemon process
* Add a settings file so that proguard-gradle examples can be run
* Document the process to publish artifacts locally for testing
* Include `proguard-core` in the API dependencies of `base`
Many of the public types in the `proguard-base` module export types that
are defined in the `proguard-core` module. This means that these `proguard-core`
types are required when compiling againt `proguard-base`.
By declaring `proguard-base` as a `java-library` and including `proguard-core`
as an API dependency, consumers of `proguard-base` do not have to declare this
explicit dependency.
* Include `proguard-base` as an API dependency of `proguard-gradle`
The public type of `ProGuardTask` exports a number of types defined in
the `proguard-base` module (`Configuration`, `ParseException`, etc). These types
are required when compiling against `ProGuardTask`, and can result in compilation
error when missing.
The correct way to model this in Gradle is to include `proguard-base` as an
API dependency of `proguard-gradle`.
