Selenium as Optional Dependency

[semperos]

I plan to remove the direct, transitive Selenium-WebDriver dependencies from the project in an upcoming release.

Of course, the library is still designed and intended to be used with Selenium-WebDriver, but given how often that project is updated and the slowness with which I've been able to maintain clj-webdriver, I think there will be less "version churn" if clj-webdriver doesn't have a hard dependency on one particular version of the Selenium-WebDriver artifacts.

I'm open to suggestions about the way in which this is done, if anyone feels strongly. I will explore requiring/importing things dynamically to allow throwing a meaningful exception if folks forget to add their own selenium-* dependencies before running clj-webdriver. However, if that overly complicates the use of the library or the code base itself, I may simply fall back to "read the documentation" and let the inevitable ClassNotFound errors guide those who haven't.

-Daniel

[Mayank Jain]

Sounds good but how would you make sure that the code works for various versions of WebDriver?

--
You received this message because you are subscribed to the Google Groups "clj-webdriver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clj-webdrive...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Regards,
Mayank.

[Daniel Gregoire]

My main intention would be to keep the Clojure codebase API compatible with the latest version of the Selenium-WebDriver dependencies. Unless there are breaking changes to the Selenium-WebDriver API's, there are usually no code changes that need to be done when upgrading the Selenium-WebDriver dependencies for clj-webdriver. By doing things this way, folks can submit issues to clj-webdriver for specific things that break or new features that clj-webdriver doesn't yet support in the latest Selenium-WebDriver releases, instead of having to open tickets just to get the version of Selenium-WebDriver bumped.

Some libraries and frameworks with optional or pluggable dependencies create separate artifacts for specific versions of those dependencies. For clj-webdriver, that would look like "clj-webdriver/clj-webdriver_2.38.0" and "clj-webdriver/clj-webdriver_2.39.0", where those numbers after the underscore would be versions of Selenium-WebDriver used. But in the case of Selenium-WebDriver, I think most people upgrade their version of it primarily to get access to testing the latest versions of browsers they target, and less for specific sets of breaking API features in the Selenium-WebDriver library itself. With this in mind, clj-webdriver should be compatible with the latest released version of Selenium-WebDriver (nothing should break when you load clj-webdriver), but the onus for maintaining some kind of backwards compatibility for browsers rests with Selenium-WebDriver itself.

[Aditya Athalye]

I don't know enough about dependency management to analyse
alternatives, but this reads like a sound plan.

Also 'read the docs' sounds like the most straightforward way to go
about it. I reckon doing something like dynamic require will merit
explanation in the docs anyway, to guide users when we make mistakes.

> --
> You received this message because you are subscribed to the Google Groups
> "clj-webdriver" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clj-webdrive...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>


--

Aditya Athalye
www.adityaathalye.com

[Mayank Jain]

Sounds good to me.

Regards,
Mayank.