[SOLR-15614] versions.lock is not including all jars in all configurations - ex: server.libExt

• Type: Task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Labels: gradle
• Assignee: Unassigned
• Reporter: Chris M. Hostetter
• Created: 01/Sep/21 22:13
• Updated: 28/Sep/21 20:27

Description

Found while working on SOLR-15610: There are (at least one) gradle "configurations" in our build system that depend on jars which are overlooked by the versions.lock logic provided by gradle's palantir plugin validation logic.

We should either simplify the configurations to work better with palantir, or find some way to force palantir to consider all configurations...

I'm not sure. Looks like this configuration is not included in what palantir's plugin considers for resolution?

https://github.com/palantir/gradle-consistent-versions#versionslock-compact-representation-of-your-prod-classpath

"The lockfile sources production dependencies from the compileClasspath and runtimeClasspath configurations, and test dependencies from the compile/runtime classpaths of any source set that ends in test (e.g. test, integrationTest, eteTest)."

But then it says that the constraints are applied to all configurations (that's why it works, I guess):
"By default, this plugin will apply the constraints from versions.props to all configurations."

...

Part of the problem is definitely that libExt is not part of the project's Java's classpath. This was done on purpose - libExt collects JARs that shouldn't be visible on classpath by default but are part of the server. I think this could be cleaned up and be moved to runtimeOnly configuration... but I'm not sure what consequences this will have since this is really a bit convoluted part of the build (trying to simulate what ant did).