Use full path of executables; working directory isn't used

In this release, I resolved a bug in Appium support that rendered executables that weren't on the path unusable. Even specifying the path through the associated setting was ineffective. This was the result of a misunderstanding about how the "working directory" would be applied. This setting isn't considered when trying to resolve the absolute path of the specified executable. For executables specified solely by name, only the system path specification is used for this purpose.

I now specify the full paths of executables, and I don't bother setting the working directory.

Add properties to propagate for Appium plug-ins

When I create the AbstractAppiumPlugin class, I neglected to add the list of System properties that should be propagated to the Java child process that launches the Appium Grid node. This release resolves this issue.

Add Mac2 page class/test; final/(un)boxing cleanup

In this release, I added a page model and test class for validating the Mac2Plugin. I also did a bit of overdue clean-up:

• Where possible, I classified a few fields as final
• I removed some unnecessary boxing and unboxing
• I revised a few variable names to flag "eaten" exceptions
• I removed all of the NOSONAR tags

Finish implementing WindowsPlugin support

In this release, I finished up the implementation of WindowsPlugin. This includes a couple of tweaks to account for the response to an unsupported method (pageLoadTimeout) and the fact that there's no direct navigation with the Windows automation engine.

Upgrade HtmlUnitDriver to version 2.63.0

v26.1.2

Upgrade to the latest dependencies

In this release, I updated to the latest releases of Settings, JUnit Foundation, and TestNG Foundation.

Apply the secret sauce to get Espresso working

In this release, I applied the workaround documented here to enable automation of Android applications with the Appium Espresso engine. I needed to tweak a few things to make everything happy, and I also discovered a bug in the approach I'd used to ensure that the "personality" value was always included in desired capabilities objects.

Add the ability to manage local stand-alone Appium server instances

In this release, I refined the management of Appium node servers to enable management of local stand-alone instances. I revised the storage of custom Selenium Foundation options to conform with W3C specifications. I also fixed a defect in the strategy used to extract driver capabilities records from node capabilities.

• GridUtility:
  • Revise the getNodeCapabilities method to return the single object supplied by the node instead of a one-item array.
  • Add new getNodeDriverCaps method to extract the driver capabilities records contained in the node capabilities object.
  • Revise the getPersonality method to accept a Capabilities object and to check "nord:options" for the "personality" value.
  • Add new getNordOptions method to extract the "nord:options" capability from Capabilities objects.
• SeleniumGrid:
  • Revise the addNodePersonalities method to take advantage of new and revised GridUtility methods.
  • Revise the shutdown method to try the AppiumGridServer.shutdownAppiumWithPM2 method for local node servers.
• TargetType:
  • Revise the matches method to get "personality" and "pluginClass" from the "nord:options" capability.
• AbstractAppiumPlugin:
  • Revise the create method to add the "appiumWithPM2" option to the node capabilities if PM2 was used to launch Appium.
  • Extract the core implementation of the shutdown method into a new static shutdownAppiumWithPM2 method.
  • Add new static shutdownAppiumWithPM2 method to enable GridServer objects created for active local node servers to shut down stand-alone Appium nodes.
  • Add new static isAppiumWithPM2 method to determine if the specified URL serves an Appium node running with PM2.
• Driver Plugins: Move custom Selenium Foundation options into a new "nord:options" capability.

For stand-alone operation, use 'pm2' as the execution context for 'appium'

Selenium Grid node servers implemented in Java that extend RemoteWebDriver are launched via GridLauncherV3, automatically spawning as stand-alone processes. By contrast, Appium runs as a child process of the execution context that launches it. This doesn't present any particular challenge when running a collection of tests that use Selenium Foundation to manage a Grid instance that exists only while the tests are running.

For execution as a stand-alone process, I added the ability to use the PM2 process manager as the execution context for the Appium node server. This feature must be explicitly activated with the APPIUM_WITH_PM2 configuration settings.

Major update to enable Android automation, including "target platform" support

In this release, I finally deployed functioning support for Android application tests. To get this all working smoothly, I needed to make fundamental revisions to the behavior of the Local Grid feature. These changes break backward compatibility, which is why this release got a major-version bump.

• I revised the instantiation behavior of Local Grid instances to separate the creation of the hub/node model from the launch of the associated Grid servers. These revisions included renaming existing methods (start/launch → create), adding a new activate method to activate the local Grid instance, and adding a new start method that's solely focused on starting the local Grid server processes, ensuring that the servers are active and registered.
• The "personality" records returned by driver plug-ins now specify the class of the plug-in with which they're associated.
• I tweaked the behavior of the AbstractSeleniumConfig.getModifications method to ensure that Capabilities for Grid nodes and driver requests will always specify "personality".
• Prior to instantiating a driver, I ensure that the local Grid is activated. I also remove the "personality" and "pluginClass" capabilities from the request, which are proprietary and will be rejected by strict W3C-compliant providers.
• These revisions enabled me to modify the implementation of the target platform feature to avoid launching a Grid or instantiating a driver if the tests associated with the active platforms don't need them.
• To enable instantiation of drivers by plug-ins that require target-specific drivers (e.g. - AndroidDriver), I added a new method to the DriverPlugin interface that returns a constructor for the associated driver class.
• I revised the definition and realization of the @PageUrl annotation to add support for Android application "activities".
• I implemented and applied a platform set for the unit tests. This enabled me to implement a test class and page model for the first Android application unit test. Existing web application unit test classes have been revised to extend the new TestNgTargetRoot and JUnitTargetRoot classes, adding corresponding @TargetPlatform annotations to existing test methods,
• I wrapped calls to commands that aren't supported by Appium drivers to catch UnsupportedCommandException.
• I tweaked the code that locates the Appium main script to ignore potential preamble (info and warning messages).
• I updated a few deprecated references to the TimeUnit class to their Duration class equivalents.
• I added a skipTest method to the TestBase class to provide a framework-agnostic mechanism for aborting a test.
• I removed a few explicit class references to static methods within the same class.
• I pared down the debug message posted by DataUtils.fromString to omit the exception stack frames.
• I removed workaround code in the ExamplePageServlet class for a Selenium 2 Grid issue.
• I updated GridUtilityTest.testIsActive to work with the new activation behavior of local Grid instances.
• I also removed a couple of deprecated methods and references to the Selenium 2 API in documentation and code comments.