Tags: mmdevlpr/proguard
Tags
Improve handling of Gradle task inputs and outputs (Guardsquare#139) 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: Guardsquare#139, Guardsquare#106, Guardsquare#136
PreviousNext