Lock plugin silently failing

[rjbrock]

I am not sure why this is happening, and it very well could be something we have in our config, but it appears that the dependency lock plugin isnt actually locking dependencies.

Build Info:
Building for android, using gradle 2.1 & dependency lock 4.2.0

I dont see any errors, and the dependency lock file was generated via ./gradlew generateLock saveLock. This created a lock file with 2 configurations, "compile" and "testCompile" (we limited it to just these 2).

When running ./gradlew assembleDebug it does not obey the lock file. But if I change "compile" to "global" it obeys the lock file. Is there something I am missing here?

Thanks!

[DanielThomas]

Without seeing the build, I'd guess that the limiting of the configurations to compile and testCompile that's the problem. In earlier dependency lock releases, the configurations you configured determined the source of locks for all configuration. The plugin now locks per-configuration, so restricting the configurations will result in surprising behavior if you're used to the old way - in this case, neither runtime or testRuntime would be locked, for example.

[rjbrock]

Thanks for getting back to me @DanielThomas. When I ran this without limiting the configurations, runtime was not one of the options. We have compile, testcompile, and a handful of others (ie pmd, jacoco, etc) that werent related to building the actual app.

[rjbrock]

Oh and I should add, even when removing the config limitations, it still does not lock the dependencies

[DanielThomas]

Odd. I assume the project isn't OSS, so we'd need a reduced test case that reproduces the issue to help. Are you able to reproduce the issue with a bare bones project?

[rjbrock]

Hi Daniel, yeah its not OSS. I did create a test project here: https://github.com/rjbrock/DependencyLocktest

I generated the build.gradle file by running ./gradlew --refresh-dependencies generateLock saveLock

commons-io is locked at 2.4 but when I sync it pulls in 2.5

[DanielThomas]

Looks right to me. You have a dynamic dependency on commons-io:

compile 'commons-io:commons-io:2.+'

Here's with the lock:

gw :app:dI --dependency commons-io --configuration compile

commons-io:commons-io:2.4 (forced)

commons-io:commons-io:2.+ -> 2.4
\--- compile

And without the lock:

gw :app:dI --dependency commons-io --configuration compile -PdependencyLock.ignore=true

commons-io:commons-io:2.5

commons-io:commons-io:2.+ -> 2.5
\--- compile

So it stands to reason, that generating the lock is going to get you the latest 2.x version; that's what you asked for. This is exactly the pattern what dependency lock was intended for: use dynamic and latest.* dependencies in your build, periodically updating with the latest releases by updating the lock file.

[rjbrock]

Sorry, let me clarify. Generating the lock works perfectly. The problem is that when the dependencies.lock file has version 2.4 locked, doing something like assembleDebug will still bring in version 2.5.

[DanielThomas]

Ah, the Android plugin must be making copies of the configurations in a way that doesn't copy the forces, or before the forces are applied:

------------------------------------------------------------
Project :app
------------------------------------------------------------

_debugAndroidTestApk - ## Internal use, do not manually configure ##
No dependencies

_debugAndroidTestCompile - ## Internal use, do not manually configure ##
No dependencies

_debugApk - ## Internal use, do not manually configure ##
+--- com.android.support:appcompat-v7:23.1.0
|    \--- com.android.support:support-v4:23.1.0
|         \--- com.android.support:support-annotations:23.1.0
+--- org.apache.commons:commons-collections4:4.+ -> 4.1
+--- org.apache.commons:commons-lang3:3.+ -> 3.4
\--- commons-io:commons-io:2.+ -> 2.5

_debugCompile - ## Internal use, do not manually configure ##
+--- com.android.support:appcompat-v7:23.1.0
|    \--- com.android.support:support-v4:23.1.0
|         \--- com.android.support:support-annotations:23.1.0
+--- org.apache.commons:commons-collections4:4.+ -> 4.1
+--- org.apache.commons:commons-lang3:3.+ -> 3.4
\--- commons-io:commons-io:2.+ -> 2.5

_debugUnitTestApk - ## Internal use, do not manually configure ##
\--- junit:junit:4.12
     \--- org.hamcrest:hamcrest-core:1.3

_debugUnitTestCompile - ## Internal use, do not manually configure ##
\--- junit:junit:4.12
     \--- org.hamcrest:hamcrest-core:1.3

_releaseApk - ## Internal use, do not manually configure ##
+--- com.android.support:appcompat-v7:23.1.0
|    \--- com.android.support:support-v4:23.1.0
|         \--- com.android.support:support-annotations:23.1.0
+--- org.apache.commons:commons-collections4:4.+ -> 4.1
+--- org.apache.commons:commons-lang3:3.+ -> 3.4
\--- commons-io:commons-io:2.+ -> 2.5

_releaseCompile - ## Internal use, do not manually configure ##
+--- com.android.support:appcompat-v7:23.1.0
|    \--- com.android.support:support-v4:23.1.0
|         \--- com.android.support:support-annotations:23.1.0
+--- org.apache.commons:commons-collections4:4.+ -> 4.1
+--- org.apache.commons:commons-lang3:3.+ -> 3.4
\--- commons-io:commons-io:2.+ -> 2.5

The plugin doesn't lock these configurations. I'll see what's preventing them from being seen.

[rjbrock]

@DanielThomas ah ok, thanks! Edit: sorry, didnt meant to close the issue

[DanielThomas]

If the configurationNames extension property isn't set, we generate it in the same code that's responsible for applying the lock. Even when running in an afterEvaluate we beat the Android plugin to the punch and read the configuration names before those internal ones are created:

private void applyLockToResolutionStrategy(DependencyLockExtension extension, Map overrides, String globalLockFileName, String clLockFileName) {
    if (extension.configurationNames.empty) {
        extension.configurationNames = project.configurations.collect { it.name }
    }

We should be able to move that logic to within the convention mappings so it's deferred until the task is ready to run. In the meantime, workaround the issue by adding all of the configurations to the configurationNames extension.

@rspieldenner can you pass an eye over DependencyLockPlugin and give me a second opinion on moving the default logic for populating the configuration names into the convention mappings for the generation tasks?

[rjbrock]

@DanielThomas Awesome thanks!

Do you happen to know when you will be doing another release?

[DanielThomas]

@rjbrock today! Look for the release in the next few minutes.

[rjbrock]

@DanielThomas Wow, thats a great turnaround time. Thanks again for the help!

[DanielThomas]

No worries! Appreciate the report - this use case allowed us to make the plugin immensely more reliable and predictable than would have been possible if we were only optimizing for eachDependency vs force.