[🚀 Feature]: Cache Selenium Manager

Feature and motivation

Right now, Java is decompressing the binary and putting it in a temp file, and all the other bindings are using them directly from where they are stored from within the respective package.

One option is to have the bindings as part of getBinary():

1. check to see if the manager exists at a designated location (~/.cache/selenium/selenium-manager/mac64/selenium-manager)
2. If it is get the version
3. Compare the version to the “latest” (to start with we should keep this a constant with the selenium version being used)
4. If it is the latest, use it, if it isn’t decompress/stream/move from package to the cache location

The advantages are:

1. No copying to temp files
2. It would be the first step for Selenium Manager Manager (#11358) if we went that route
3. I can just copy test binaries into the system directory to test them instead of needing to go through bazel (hard in some language, and actually impossible in .NET right now)

Usage example

n/a

[bonigarcia]

How is it more unique than the drivers? Seems they should be treated the same, either way?

I consider it different things. For me, Selenium Manager is a tool that manages drivers, which means, in short, that it downloads drivers automatically. But Selenium Manager does not know the user’s intentions regarding the downloaded driver. Maybe they will be executed on the local machine, or perhaps they are intended for other uses (e.g., hosted and served on a server). In any case, Selenium Manager should be able to download drivers even for a different platform that the local host.

Regarding the selenium-manager binary, it is placed in that path by the binding, with the intention of running it. So there is only a possible binary, at least at this moment.

[titusfortner]

Aha, I see what you’re suggesting now. That works. Thanks.