Applying this plugin breaks existing assemble task dependencies

[seanabraham]

Plugin version
0.65.0

Gradle version
6.2.1

Android Gradle Plugin (AGP) version
N/A

Describe the bug
Applying this plugin seems to clear all archives artifacts, therefore rendering the assemble task useless (i.e. assemble no longer depends on the tasks it used to and produces the artifacts it would have in the absence of the Dependency Analysis plugin being applied). This is problematic in projects where the assemble task is actually in use.

I believe this line is the cause: https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/blob/2c193d55a7891b7c6f31e8079a745439db8844f8/src/main/kotlin/com/autonomousapps/DependencyAnalysisPlugin.kt#L938

To Reproduce
Steps to reproduce the behavior:

1. Apply Gradle application plugin to a project
2. Run assemble on said project, see jar task among others run
3. Apply this plugin
4. Run assemble again and see no other tasks run.

Expected behavior
I would expect the existing behavior of the assemble task to not break (even if it is a goofy task set to be deprecated).

[autonomousapps]

Thanks for the issue.

I added that line with some reluctance, and only after a long conversation with a gradle core eng. As you say, assemble is a goofy task set to be deprecated. Not clearing its artifacts would be even worse for some common use-cases with most of my users.

That said, I do understand your situation and would like to help. What about adding a configuration via a system property? For example:

pluginManager.withPlugin("base") {
  if (System.getProperty("foo", "true")!!.toBoolean()) configurations["archives"].artifacts.clear()
}

and you could add sysProp.foo=false to your gradle.properties.

[seanabraham]

This would work for us, if you're comfortable with a change like this. One thought — it's not possible to selectively remove the artifacts you're creating from being added to archives, right? Or similarly, not add them in the first place (maybe somehow via variants?)

We may also be able to work around this but I still wanted to make sure to create this issue since others might run into it and it was definitely confusing behavior on plugin application (though such is life to a degree with Gradle plugins).

[autonomousapps]

I actually already have a PR up testing the change out. There's some kind of test failure I'll dig into tomorrow.  I don't mind the change, since I agree the default behavior can be confusing for a case like yours.  We tried selectively removing artifacts, but for reasons unknown it did not work. Hence the issue link near this block of code. And as I said, I consulted with a couple of Gradle engs on this, and what I have now is actually their suggested solution. 

On November 18, 2020, GitHub ***@***.***> wrote: This would work for us, if you're comfortable with a change like this. One thought — it's not possible to selectively remove the artifacts you're creating from being added to archives, right? Or similarly, not add them in the first place (maybe somehow via variants?) We may also be able to work around this but I still wanted to make sure to create this issue since others might run into it and it was definitely confusing behavior on plugin application (though such is life to a degree with Gradle plugins).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/autonomousapps/dependency-analysis-android-gradle- plugin/issues/321#issuecomment-730117764>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/ABJG5PJ43WMGJJNHMBWMODLSQSLRTANCNFSM4T2PFDHQ>.

[autonomousapps]

This will be released as 0.66.0. You should set the system property dependency.analysis.clear.artifacts=false.