Use ChromeOptions and FirefoxOptions instead of DesiredCapabilities

[pavelpp]

The latest and recommended way to request a RemoteWebDriver is by passing ChromeOptions / FirefoxOptions to the constructor instead of DesiredCapabilities. Both of these implement Capabilities interface so the change was quite straightforward, deprecating the old method and changing the field type to Capabilities.

Another improvement is that we will not throw IllegalException when capabilities are not provided, but fall back to starting a chrome container. So now you could just write:

@Rule
public BrowserWebDriverContainer chrome = new BrowserWebDriverContainer();

omitting withCapabilities(new ChromeOptions()) and it will work out of the box.

[rnorth]

I'd just like to clarify whether this is a 'breaking change' for our users or not. I fear that it could be.

Because our Selenium dependency is provided scope, we let the user control the version. The API looks like it's backwards compatible, but will our code work with Selenium 2.x.x libraries? Has anybody tested this?

[pavelpp]

@rnorth Good point, I will test this locally in a dummy project when I find some more time

[pavelpp]

Updated fallback to Chrome when selenium version is 2.x. Now if detected Selenium version is 2.x, we will use DesiredCapabilities.chrome() and with newer Selenium versions - ChromeOptions() as a fallback with unspecified capabilities. That was the only issue I found. Verified locally with a dummy project and Selenium 2.53.1 dependency - works like a charm.

[kiview]

PR LGTM.

Just for clarification, using DesiredCapabilities is deprecated?
Will the class get removed in the future?

We probably also have to update the docs.

[rnorth]

Thanks for addressing my query @pavelpp - LGTM

[kiview]

Thanks for your contribution @pavelpp, merged!