palantir / gradle-consistent-versions

Compact, constraint-friendly lockfiles for your dependencies
Apache License 2.0
117 stars 14 forks source link

Unclear antlr configuration resolution issue with 1.12.1 #254

Open mglazer opened 5 years ago

mglazer commented 5 years ago

What happened?

There seems to be another 1.12.1 regression which I'm unsure if it's the same as #221

We depend on the Gradle ANTLR plugin, and apply it in dependencies like so:

dependencies {
  antlr 'org.antlr:antlr4'
}

With the 1.12.1 upgrade, I had to modify this to:

dependencies {
  antlr 'org.antlr:antlr4:4.7.2'
}

Or else I got:

* What went wrong:
Execution failed for task ':project-function:formula-function-grammar:generateGrammarSource'.
> Could not resolve all files for configuration ':project-function:formula-function-grammar:antlr'.
   > Could not find org.antlr:antlr4:.
     Required by:
         project :project-function:formula-function-grammar

What did you want to happen?

I expected to not have to specify a version for the ANTLR configuration.

dansanduleac commented 5 years ago

This is because we attempted to stop exposing versions.props constraints in the published POM (#193). In order to achieve that, we had to stop injecting constraints into all configurations that funnel down to the published configurations via inheritance - apiElements and runtimeElements.

Concretely, this suggests that antlr is inherited by a superconfiguration of apiElements or runtimeElements, like compile, e.g.

 sourceSets { antlr }

 configurations {
-    compile.extendsFrom antlrCompile
+    compileClasspath.extendsFrom antlrCompileClasspath
 }

If you make sure never to modify compile and instead do this sort of stuff from compileClasspath then the problem should go away.

dweiss commented 5 years ago

This workaround won't work if you don't have control over the configuration you're using for dependencies -- the war plugin is an example (GH-313)