Adds README section about dynamically added dependencies#24
Adds README section about dynamically added dependencies#24rzetterberg wants to merge 1 commit intoraphiz:mainfrom
Conversation
Presents an explanation, an example and the solution to the specific problem of Gradle dependencies being added dynamically inside a Gradle task, instead of being statically listed in `dependencies { ... }`.
raphiz
left a comment
raphiz
left a comment
There was a problem hiding this comment.
Awesome, thanks for your Contribution!
That's a good issue to document! I've come across it a few times, but never taken the time to write it down.
| @@ -58,6 +58,26 @@ Here is an example command to let Gradle add all dependency artifacts to your `v | |||
| gradle --refresh-dependencies --write-verification-metadata sha256 --write-locks dependencies | |||
| ``` | |||
|
|
|||
There was a problem hiding this comment.
I think we could give this section a title of its own, e.g. Detached Configurations (can't think of anything better at the moment - may be more descriptive...).
| ``` | ||
|
|
||
| Now you will notice that the `verification-metadata.xml` file will contain those extra missing dependencies that you got an error for earlier. | ||
|
|
There was a problem hiding this comment.
When adding headings, I would add another heading here (something like Keeping the verification-metadata.xml clean)
| gradle --refresh-dependencies --write-verification-metadata sha256 --write-locks dependencies | ||
| ``` | ||
|
|
||
| Note that in Gradle projects where dependencies are specified dynamically inside a Gradle task, you need to run the same command above, but replace `dependencies` with the specific Gradle task where dependencies are dynamically specified. |
There was a problem hiding this comment.
I'm not 100% sure if replacing the dependencies is always a good idea (depending on lazy evaluation and/or project isolation, this might not resolve everything). I would recommend executing both (or "all relevant") tasks, e.g. gradle dependencies :sub-project1:compileGroovy :sub-project2:compileTestGroovy.
There was a problem hiding this comment.
Yes, I agree! What I tried to convey was that you first run the dependencies task, then if you encounter a problem you take the same command, replace dependencies with your task and re-run it.
I'll add a new heading and rephrase everything a bit and see if I can come up with something that is more clear.
2 participants
Presents an explanation, an example and the solution to the specific problem of Gradle dependencies being added dynamically inside a Gradle task, instead of being statically listed in
dependencies { ... }.