Initial Creation of the Selenium CLI Tool

[AutomatedTester]

This adds the P0 tasks from this product brief in #17326

🔗 Related Issues

💥 What does this PR do?

🔧 Implementation Notes

💡 Additional Considerations

🔄 Types of changes

• Cleanup (formatting, renaming)
• Bug fix (backwards compatible)
• New feature (non-breaking change which adds functionality and tests!)
• Breaking change (fix or feature that would cause existing functionality to change)

[bonigarcia]

I think #17326 is a great idea. Thanks a lot, @AutomatedTester, for leading this effort.

About #17327, my main concern is duplication. This PR proposes using the Selenium Manager Rust core as the basis for two CLIs: selenium-manager and sel. But personally, I don't see a big benefit of having two separate CLIs.

As an idea. What if we rebrand "Selenium Manager" to "Selenium CLI" and make it the only CLI tool for the Selenium project?

This PR will become much simpler. We should only need to include the new module (jre.rs) in the new "Selenium CLI" and the required logic to use it. This will avoid all the duplicated code in both CLIs (e.g., lines 57 to 166 in sel.rs) or the setup and use of SM (lines 331 to 354 in sel.rs).

What do you think?

[nvborisenko]

+1 for unified tool. SM could be just a command.

selenium manager install --browser chrome

Also sel looks so short, selenium is more concise.

[AutomatedTester]

I think Selenium Manager doesn't convey the direction of where I think this tools should go. I am happy, like @nvborisenko suggests, to have this as selenium and we can move manager to a separate command. I am not sure it's fully needed.

[AutomatedTester]

PR Implementation Checklist

Direction and Scope

• Confirm in PR conversation that we are moving to a single CLI implementation to eliminate duplication.
• State that this PR focuses on P0 + deduplication, and that command UX expansion will be follow-up work if needed.
• Mark duplication concern from reviewers as addressed once code changes are pushed.

Remove Duplicate CLI Surface

• Remove the separate sel binary entry from rust/Cargo.toml.
• Remove the separate sel Bazel target from rust/BUILD.bazel.
• Remove or retire the separate sel binary implementation in rust/src/bin/sel.rs.
• Remove sel-specific test target wiring in rust/tests/BUILD.bazel.
• Remove sel test helper from rust/tests/common.rs.
• Remove sel-specific test file rust/tests/sel_cli_tests.rs.

Keep and Integrate P0 Value in Existing CLI

• Keep JRE support module in rust/src/jre.rs.
• Keep module export in rust/src/lib.rs.
• Integrate JRE ensure flow into existing Grid path in rust/src/main.rs so Grid works without requiring preinstalled Java.
• Ensure behavior remains compatible with current selenium-manager invocation patterns used by bindings.

Testing and Validation

• Add or update Grid/JRE integration coverage in rust/tests/grid_tests.rs.
• Keep unit coverage for Java version parsing/runtime detection in rust/src/jre.rs.
• Run targeted build/test for affected Rust targets.
• Run at least one integration path covering Grid setup with JRE resolution.
• Confirm no regressions in existing selenium-manager behavior.

PR Hygiene

• Update PR description to reflect single-tool architecture and removed duplication.
• Summarize reviewer feedback and how each point was addressed.
• Include short risk note and fallback behavior for JRE resolution.
• Request re-review after all checklist items above are complete.

Definition of Done

• One CLI path remains in Rust (no duplicated manager setup logic).
• Grid path can resolve Java automatically (system Java 11+ or managed JRE cache).
• Existing selenium-manager consumers remain backward compatible.
• Tests for touched paths are green.
• Reviewer duplication concern is clearly closed in the PR thread.