Gradle task licenses.plugin.DependencyTask is never cached

[hardysim]

Just like #58 but for com.google.android.gms.oss.licenses.plugin.DependencyTask .

[hardysim]

Using the new Build Analyzer in Android Studio 4.0 there's a warning for this as well. Here's the report:

At 11:23, Feb 26, 2020, Android Studio detected an issue with Gradle plugin com.google.android.gms.oss-licenses-plugin

Always-run Tasks
Task runs on every build because it declares no outputs.

Plugin: com.google.android.gms.oss-licenses-plugin
Task: getDependencies
Task type: com.google.android.gms.oss.licenses.plugin.DependencyTask
Issue detected in 1 module(s), total execution time was 0,045 s (6,4%), by module:
  Execution mode: FULL, time: 0,045 s (6,4%), determines build duration: false, on critical path: false

====Build information:====
Execution date: 26.02.2020 11:23
Total build duration: 1,945 s
Configuration time: 0,490 s (25,2%)
Critical path tasks time: 0,699 s (35,9%)
Critical path tasks size: 100
AGP versions: 4.0.0-beta01
====Platform information:====
AI-193.6494.35.40.6220182, JRE 1.8.0_212-release-1586-b04x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1080x1920, 2560x1440, 2560x1440

AS: 4.0 Beta 1; Kotlin plugin: 1.3.61; Android Gradle Plugin: 4.0.0-beta01; Gradle: 6.2; NDK: from local.properties: (not specified), latest from SDK: 21.0.6113669; LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: 3.10.2, from PATH: (not found)

[ubuntudroid]

Android Studio 4.0 beta1 screenshot of the behavior @hardysim is describing:

[alixwar]

Android Studio 4.0 (release) still complains:

At 13:18, Jun 01, 2020, Android Studio detected an issue with Gradle plugin com.google.android.gms.oss-licenses-plugin

Always-run Tasks
Task runs on every build because it declares no outputs.

Plugin: com.google.android.gms.oss-licenses-plugin
Task: getDependencies
Task type: com.google.android.gms.oss.licenses.plugin.DependencyTask
Issue detected in 1 module(s), total execution time was 0,103 s (4,4%), by module:
  Execution mode: FULL, time: 0,103 s (4,4%), determines build duration: true, on critical path: true

====Build information:====
Execution date: 2020-06-01 13:18
Total build duration: 2,899 s
Configuration time: 0,156 s (5,4%)
Critical path tasks time: 2,316 s (79,9%)
Critical path tasks size: 70
AGP versions:
====Platform information:====
AI-193.6911.18.40.6514223, JRE 1.8.0_242-release-1644-b01x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1920x1080

AS: 4.0; Kotlin plugin: 1.3.72-release-Studio4.0-1; Android Gradle Plugin: 4.0.0; Gradle: 6.4.1; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)

[johnjohndoe]

I can confirm that as soon as you apply the com.google.android.gms:oss-licenses-plugin:0.10.2 plugin to a project then the com.google.android.gms.oss.licenses.plugin.DependencyTask will run on every build. I tested this with a new project created with Android Studio 4.2 Canary 2. Here is the build scan report which clearly shows the issue.

Just run ./gradlew assembleDebug --scan twice and take a look at the second build scan report.

Related

• getDependencies task is run on every build #146 getDependencies task is run on every build

[johnjohndoe]

@runningcode Do you see how the task is misconfigured here?

[runningcode]

I'm going to guess that this is happening because the outputs are not declared properly. they are placed on groovy fields instead of on the groovy properties. A very subtle distinction. This PR will likely fix it:
https://github.com/google/play-services-plugins/pull/111/files

[johnjohndoe]

Nice. Thanks for pointing out the PR. I hope the maintainers will pick it up soon. @PaulRashidi

[PaulRashidi]

I actually transitioned to a new team a year and a half ago. I might suggest you split the PR into a no-op one (getter switches and such) and one that fixes the issue in this thread.

FYI, @caller9

[johnjohndoe]

@lptr Can you provide a stripped down PR as suggested by @PaulRashidi?

[lptr]

Sorry, I'm lacking some context here. What PR are you asking me to do?

[johnjohndoe]

As far as I can tell your #111 PR contains the bugfix for the issue described here. I understand @PaulRashidi so that he would like to have a minimum PR only containing the bugfix.

[schuenadel]

I have created PR #152 to fix this issue in a minimal way. Could someone please check it?