I'm working on a gradle build for Apache Lucene and we're getting false hits with this patch. checkUnusedConstraints fails check and reports an extra dependency, --fix removes it.

[dansanduleac]

I'm working on a gradle build for Apache Lucene and we're getting false hits with GCV 1.14.0. checkUnusedConstraints fails check and reports an extra dependency, --fix removes it.

git clone https://github.com/apache/lucene-solr -b gradle-master --depth 1
cd lucene-solr
git checkout 0166e89dba1359f443067750789aae36c2d6d35c
./gradlew checkUnusedConstraints

reports:

> There are unused pins in your versions.props:
  [com.fasterxml.woodstox:*, org.apache.commons:commons-collections4:4.2, info.ganglia.gmetric4j:gmetric4j, org.apache.pdfbox:jbig2-imageio]

But at least one of these dependencies is actually used in a submodule (explicitly):
https://github.com/apache/lucene-solr/blob/gradle-master/solr/contrib/extraction/build.gradle#L34

and when removed the build fails:

./gradlew verifyLocks
> Task :verifyLocks FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':verifyLocks'.
> Could not compute lock state from configuration 'unifiedClasspath' due to unresolved dependencies:
   * org.apache.commons:commons-collections4 (requested: 'org.apache.commons:commons-collections4' because: requested)
        Failures:
           - Could not find org.apache.commons:commons-collections4:.

Originally posted by @dweiss in #365 (comment)

[dansanduleac]

@dweiss taking a look, thanks for the report! Made an issue so it's easier to track

[dweiss]

Thanks @dansanduleac Lucene has a fairly hairy build - I'm sorry for that - but something is definitely off. There is also another issue I hit (on a different project) when upgrading to the newest version results in an exception; don't know if it's something known. I didn't look deep into that yet.

[dansanduleac]

Looks like we need to be stricter when parsing versions.props!

Spot the odd one out:

org.apache.calcite.avatica:avatica-core=1.13.0
org.apache.calcite:*=1.18.0
org.apache.commons:commons-collections4:4.2
org.apache.commons:commons-compress=1.19
org.apache.commons:commons-configuration2=2.1.1

Annoyingly it actually picks up the constraint even though you used : instead of =, but the fixer uses different parsing logic :(

[dweiss]

Darn... interesting that it passes and works before!

[dweiss]

Let me verify that it works when corrected. If so, we can close the issue.

[dansanduleac]

Unrelated, but I notice you declare dependencies using { transitive = false } which I think negates some of the advantages of using GCV, namely that transitive constraints never get read, and so don't participate in Gradle's dependency resolution.

Given that GCV gives you the full transitive classpath in versions.lock, you shouldn't need to manually specify every single transitive dependency in this way. Also, if you add new dependencies or bump them, and forget to add a transitive, then you just get ClassNotFoundException which is not fun!
Happy to chat through this if you'd like, I'm happy that you are using GCV on your project and want to make sure you're getting the most out of it 💯

[dweiss]

Trust me, it's not so simple. :) I know about it. We're looking at 15 years of legacy here and these non-transitive dependencies reflect the current state of the ant build (which runs alongside gradle for now).

I (or somebody) will definitely be cleaning these up.

[dweiss]

Thanks Dan, works like a charm.

[dansanduleac]

@dweiss you might have thought about this and there might be reasons why you can't do this, but I thought of an improvement you could make if you want to continue running an ant build: generate the ant/ivy dependencies from each project's compileClasspath and runtimeClasspath, and then update the ant XMLs via a gradle task when these change (for example, a task that is wired up to run when you run ./gradlew --write-locks).

That way, you have one source of truth that's guaranteed to be complete, rather than relying on ant as a source of truth, and GCV would ensure that the versions as resolved from those configurations are always consistent with versions.lock across all the projects.