Skip to content

Conversation

rzetterberg
Copy link

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 { ... }.

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 { ... }`.
Copy link
Owner

@raphiz raphiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

```bash
gradle --refresh-dependencies --write-verification-metadata sha256 --write-locks dependencies
```

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@rzetterberg rzetterberg marked this pull request as draft August 13, 2024 07:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants