* Revert "Improve handling of Gradle task inputs and outputs (#139)"
This reverts commit b5fbefb87c.
* Add more test coverage of Gradle plugin
- Rename `gradlekotlindsl` sample to `gradle-kotlin-dsl`
- Use `gradle-kotlin-dsl` as basis for plugin testing
- Add coverage for loading from external config file
* Register Proguard output files as Gradle task outputs
These outputs file may be consumed by other Gradle tasks, and
this change makes the output file locations available programatically.
We use this internally to publish the generated mapping file to internal
repository, which makes it easier to later deobfuscate stack traces. eg:
publishing {
publications {
register("sourcemap", MavenPublication) {
artifact tasks.named("proguard").map { it.printMappingFile }
}
}
}
Previously, Task inputs and outputs were declared in an ad-hoc manner,
resulting in confusing source code and inconsistent behaviour with up-to-date checks.
Specifically:
- If an input (`-injars`, `-libraryjars`) was configured via a ProGuard config file,
then changes to these inputs were not detected as part of up-to-date checks
- Similar for output files: if an output added with `-outjars` was deleted, the task
would not detect this and would not re-execute
- Many task inputs were not registered at all, meaning that the task would be incorrectly
considered up-to-date when these inputs were changed (eg `keep`, `dontshrink`,
`assumeNoSideEffects`, `obfuscationDictionary`, etc)
- Many output files were not tracked at all (eg printMapping). This meant that changes
to these files were not detected, and they were not restored correctly from cache.
A few further notes:
- To avoid having to wrap the `ClassSpecification` and `MemberSpecification` types
(and subtypes), these classes were declared as `Serializable`.
- The existing properties on `ProGuardTask` were left unchanged, to avoid changing the
task API and to retain support for the existing DSL configuration.
- Since `programJars` and `libraryJars` can contain a mix of files and directories,
inputs and outputs, each entry is exposed as a `WrappedClassPathEntry`, with subtypes
representing the actual input/output file/directory.
- Use a `Provider<Configuration>` to defer initial instantiation of `Configuration`
- Provider is a mapping from configuration input files, which means it will carry
task dependency information
- Provider implementation loads the configuration on first use, memoizing for later uses.
* Simplify the task configuration model to make it possible to defer loading configuration
The first attempt modeled each input file as a `@Nested` object containing the File
reference as well as the filters attached to that file. While this closely modelled
the true configuration, it meant that each nested instance was instantiated early
in order to inspect the properties.
With this change, all input files are merged into a single `FileCollection` property,
and the filters for all files are merged into a separate `List<Serializable>` property.
This structure will later allow us to defer loading these property values until the
task begins executing.
* Correctly handle output directories
By borrowing the file detection logic from Proguard core, we can determine if
a configured output file is a file (with a known extension) or a directory.
This is required to correctly register the file as an `OutputFile` or `OutputDirectory`.
Using `.isFile()` and `.isDirectory()` is not sufficient, as the file may not exist.
* Defer loading of Proguard configuration until task is executed
By default, all `@InputFile` properties are resolved when building the task
graph. By declaring these input properties as a mapping from the configuration-file
inputs, the provider contains enough context to avoid realizing the actual properties.
Since realizing these properties involves loading the Proguard configuration, this
change allows this work to be deferred until the task inputs are actually calculated
as part of task execution.
* Track direct task inputs separately, to preserve task dependencies
The input files for the proguard task are a combination of files loaded via a
configuration file and files directly configured via the Gradle DSL. The latter
can carry task dependency information, but this is being lost when we merge
the set of input files.
This change adds separate `@Classpath` properties to the task to track the files
added directly via the Gradle DSL, thus preserving task dependencies for these inputs.
* Workaround limitation in Gradle 6.x
In older versions of Gradle, all `InputFile` properties of type `Provider`
are realized when building the task graph in order to check for existence.
This happens even when these were mapped from a known producer, resulting in
early loading of the ProGuard configuration file(s).
In order to workaround this issue, a custom `Provider` implementation is
used for Gradle versions <= 7.0
* Renamed from `gradlekotlindsl` -> `gradle-kotlin-dsl`
Closes: #139, #106, #136
* 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`.
* Add cache relocatability to proguard task.
This allows the Proguard Task to take advantage of the Gradle Build cache and re-use outputs from other builds.
This also adds a simple test for cache relocateability
* Address review comments
* Use regex to replace build.gradle file
* Use jar in spring boot sample.
