Appium 2.0

Appium, rather than bundling all the separate drivers by default, becomes a driver management interface (in addition to continuing to play the role of automation frontend server). Appium gets a set of CLI tools for users to pick and choose which drivers and versions of drivers they want to use via Appium.

Spec for Appium 2.0

Additional breaking changes, upgrades, or dev tasks to perform while we are allowed to make breaking changes:

• Remove ability to use most server args (in favor of --default-capabilities)
• Remove support for appium-ios-driver (move it to boneyard and pull out shared code either into appium-xcuitest-driver or if we want, into appium-ios-base)
• Remove support for appium-android-driver (move it to boneyard and pull out shared code either into appium-uiautomator2-driver, or since espresso might also depend on it, into appium-android-base)
• Remove support for appium-selendroid-driver (move it to boneyard)
• Update all build scripts to use minimal transpilation (at this point, targeting Node 10 as a minimum, we should able to get away with very little transpilation, maybe just the import stuff?) I am not sure how easy this is to do with Babel, hopefully it is smart enough to take a target version of Node and not transpile more than necessary.
• See if we can move away from the Winston logger to something more flexible and universal that could be shared by BaseDriver. Since we’re making breaking changes we’d be OK with a log format update.
• run WDA bootstrap script on xcuitest driver install, not first session run?

(Each of the above should probably be turned into their own issue and linked here)

[jlipps]

@tirodkar hello! we’d absolutely love to integrate EarlGrey via an EarlGrey driver for Appium. Architecturally, there would be two pieces:

1. a webdriver protocol-compatible HTTP server built into EarlGrey itself (written in ObjC or whatever EarlGrey is written in). This listens for requests and performs automation actions based on the request.
2. an Appium driver proxy, written in JS and hosted on NPM. This is the glue between Appium and EarlGrey, that enables Appium users access to EarlGrey. It will bundle the EarlGrey code or binary and handle whatever launch invocations EarlGrey requires in addition to proxying to the webdriver server running in EarlGrey.

The EarlGrey team would need to handle (1), since the Appium team doesn’t know anything about that. The Appium team can handle (2), or walk you through creating that (there are a number of examples of this and it’s a pretty minimal set of code that’s required).

Of course, we can also consult on the design of (1), and that might be a good idea to avoid any incompatibilities.

The end result would be all Appium users having access to the EarlGrey technology via the universal WebDriver protocol–a real win for everyone! Please stay in touch as we’d love to facilitate this happening.

[jlipps]

Been thinking more about Appium 2.0, and made a concrete proposal for how it’d work! https://gist.github.com/jlipps/651b62316603400cabc95ff0f9faf70f

cc @imurchie @dpgraham @mykola-mokhnach @sravanmedarapu @bootstraponline @moizjv