dweiss commented on PR #14540:
URL: https://github.com/apache/lucene/pull/14540#issuecomment-2823322410

   Ok, so here's how to work this out. First, show what's bringing in the 
conflicting dependencies, like the message shows:
   
   ```
   ./gradlew :lucene:benchmark:dependencyInsight --dependency 
"commons-codec:commons-codec" --configuration "compileClasspath"
   ...
   commons-codec:commons-codec:1.17.1
   \--- org.apache.commons:commons-compress:1.27.1
        \--- compileClasspath
   
   ./gradlew :lucene:analysis:phonetic:dependencyInsight --dependency 
"commons-codec:commons-codec" --configuration "compileClasspath"
   ...
   commons-codec:commons-codec:1.17.2
   \--- compileClasspath
   ```
   
   The above means :lucene:benchmark pulls commons-codec as a transitive 
dependency and phonetic imports it directly. Previously, palantir's 
consistent-versions would try to make all dependencies "consistent" globally - 
unfortunately this isn't really working well with larger projects with more 
complicated configurations. This "dependency-locking" mechanism that I wrote 
and that we use in Lucene attempts to detect such inconsistencies but doesn't 
try to fix them. There are a few ways to fix this:
   
   * Add an explicit dependency on commons-codec or on 
:lucene:analysis:phonetic to :lucene:benchmark - then gradle will align the 
transitive dependency to the requested version. Here is what the dependency 
insight looks like after adding a dependency on phonetic:
   ```
   ./gradlew :lucene:benchmark:dependencyInsight --dependency 
"commons-codec:commons-codec" --configuration "compileClasspath"
   ...
   \--- project :lucene:analysis:phonetic
        \--- compileClasspath
   
   commons-codec:commons-codec:1.17.1 -> 1.17.2
   \--- org.apache.commons:commons-compress:1.27.1
        \--- compileClasspath
   ```
   note the auto-aligned dependency.
   
   * Add gradle's dependency constraint on the version of commons-codec to 
benchmarks.
   
   * remove :lucene:benchmark from the set of configurations included in the 
dependency lock checks 
   (this would mean two different versions of commons-codec are used in 
different configurations).
   
   I went with the first option because this seems like the simplest one. Note 
that the latest version of commons-compress
   brings additional dependencies (commons-io and commons-lang3).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to