Hi @titusfortner,
in my Java project, I use Gradle 7.5.1 and my build.gradle is as follows:

image

@bonigarcia & @asolntsev
Based on what I've read, I'm pretty sure testImplementation is the most correct. Is there a reason to use implementation? I see selenide uses api, but I think that's because it is a library dependency and not something being set by end-user? Thanks!

• With this PR, all languages will dynamically update versions on "Install Library" page based on the versions in examples

• When this PR goes through, need to change the locations of where to update Java versions for Maven & Gradle in https://github.com/SeleniumHQ/selenium/wiki/Releasing-Selenium

• For some reason this isn't building on Netlify and my local execution is showing weird things for Gradle code section. The display is wrong, but the link is correct. I'm hoping it's a weird caching error on my end, but need to verify before merging.

Is there a reason to use implementation? I see selenide uses api...

In most cases, it's reasonable to use implementation or testImplementation, and not api.

• implementation for dependencies used in production code
• testImplementation for dependencies used in test code (most probably selenium goes in this category)
• api for dependencies you use in your code, and also want your users to use also (this is why Selenide declares Selenium as api - because we assume our users most probably will use Selenium classes also. We could declare Selenium as implementation, but then Selenide users would need to add Selenium dependency explicitly in their projects).

I am assuming this is related to the pull request in SeleniumHQ/selenium about creating code examples from existing tests in the selenium repository.

@ollie-iterators yes, the goal is for us to ensure examples are kept up to date in executable code rather than in docs

Is this PR waiting for some improvement in code quality to happen in the selenium repository, or is there something more to be added to this pull request?

Needs refactoring after the recent updates to tabpanes

I think the next big thing that should be worked on after this is making it so that the test coverage can be calculated for the Selenium repository

@ollie-iterators do you mean as in what percent of Selenium features are documented in this repo? Or unit test coverage of the Selenium tests?

Unit coverage of the Selenium tests, because the tests will be used to make the documentation.

Also, both of those options could be the same because the areas that have tests would be used to make documentation for Selenium features in this repository.

Code coverage checks in my opinion are a bit overrated, but we definitely have a disparity of coverage between different languages. We've discussed options for this, feel free to join us and discuss in #selenium-tlc channel in Slack/Matrix - https://www.selenium.dev/support/#ChatRoom

I think that test coverage would be a good way to find out which areas need tests which, once the tests are used to create the code examples would be the same as finding areas that need code examples.

I'm rolling this into #1217