Automatic Version Updates in Docs

[titusfortner]

The goal is to automatically update versions in Documents based on current versions in examples, which requires implementing a gradle example in Java.

I'm not sure if what I put is "correct"
What is in our docs now:

dependencies {
    implementation group: 'org.seleniumhq.selenium', name: 'selenium-java', version: '4.4.0'

What I'm using:

    testImplementation 'org.seleniumhq.selenium:selenium-java:4.4.0'

Someone who knows gradle should verify the right thing, and if we need to keep examples for multiple versions of gradle, etc.

I might need to change how files are parsed to get the auto-language to work; we'll see if this PR builds.

[netlify]

✅ Deploy Preview for jovial-austin-42fe02 ready!

Name	Link
🔨 Latest commit	951a3b8
🔍 Latest deploy log	https://app.netlify.com/sites/jovial-austin-42fe02/deploys/630e1d07f85320000894994b
😎 Deploy Preview	https://deploy-preview-1147--jovial-austin-42fe02.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Dor-bl]

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

[Dor-bl]

The latest gradle version is 7.5.1. so might want to update that one :)

[titusfortner]

We aren't actually using gradle in this project right now, I just want a place to show the right code/version, so I'm less worried that this stays pegged to the latest version.

[titusfortner]

@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!

[titusfortner]

• 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.

[asolntsev]

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).

[ollie-iterators]

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

[titusfortner]

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

[ollie-iterators]

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?

[titusfortner]

Needs refactoring after the recent updates to tabpanes

[ollie-iterators]

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

[titusfortner]

@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?

[ollie-iterators]

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.

[titusfortner]

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

[ollie-iterators]

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.

[titusfortner]

I'm rolling this into #1217