malliaridis commented on PR #2809: URL: https://github.com/apache/solr/pull/2809#issuecomment-2546332902
> 1. accepting upstream locks > 2. running locally: ./gradlew writeLocks > 3. committing the diff That is the correct approach. The huge diffs in lock file come from transitive dependencies, so it is normal to have multiple changes if the new libraries have multiple transitive dependencies. You probably don't have to review the file, and I believe the current format that has changed by the plugin we use could also be simplified. **I am working on a solution for that and I think I found something interesting. So stay tuned.** > ... or just accept the diff blindly If the tests are green I believe you can accept it blindly. If there is any invalid content, running writeLocks on another machine would generate diffs and raise "suspicions", so no worries about that. :) > usedUndeclaredArtifacts This comes from a specific plugin, not directly related to dependency version alignment. Basically, a plugin checks if you use classes from libraries that are made available through transitive dependencies. What it asks you is to add the dependency explicitly so that we explicitly include what we use. And when including a library that is not used, it will also complain and report "unusedDeclaredArtifacts". I had a hard time to figure that out as well. > unusedDeclaredArtifacts > dev.langchain4j:langchain4j-cohere:0.35.0@jar -> runtime > dev.langchain4j:langchain4j-hugging-face:0.35.0@jar -> runtime > dev.langchain4j:langchain4j-mistral-ai:0.35.0@jar -> runtime > dev.langchain4j:langchain4j-open-ai:0.35.0@jar -> runtime > dev.langchain4j:langchain4j:0.35.0@jar This is the other case where this library may report false-negatives. If you are implementing a library module, you usually don't include these and let the consumer of your library add them to their dependencies, so they can choose for example the model they want to use. At least that's how I understand the plugin and how I believe the libraries you use work. So if the module you added uses these dependencies, and it is not a library used by Solr users in their own project, then it is fine to add permits and allow the dependencies to be included. I think someone commented in the past if we need these dependencies, and I believe they were thinking of that scenario. > other dep file you conveniently fixed for me @malliaridis had a couple of minor mistakes? If I recall it correctly, I fixed a few issues in the way dependencies were referenced / added, basically syntax-related issues. -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
