The AGP integration might use this constructor that was removed during a
refactor when using the legacy ProGuard integration method (dependency
substition).
Detect when an old version of proguard (net.sf.proguard:proguard-gradle) bundled with AGP < 7 is on the classpath, and print a warning showing how to exclude it.
With this change users can now wire up ProGuardTask with other tasks. Gradle will then automatically track the task dependency between ProGuard and the consuming task.
* 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
* 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.
Changes the dependency on the Android build tools to `compileOnly` and improves the error message when using the plugin in a non-Android project.
Fixes: #66
