Add default DriverPlugin methods to create local Grid nodes

In this release, I did a bit of refactoring to provide methods to enable the addition of local nodes to an active Grid collection.

Start all Grid servers, then wait for active/register

In this release, I revised the launch strategy for local Selenium Grid collections to start the servers in quick succession, then wait for the entire collection to be active and all of the nodes to be registered. This noticeably reduces the launch delay experienced with the previous one-at-a-time strategy.

I revised the matching strategy for skipping interface methods in "enhanced" object, using just the method name rather than the full signature. This prevents infinite recursion (stack overflow) that occurred when the interceptor invoked one of these methods on an "enhanced" object that doesn't directly implement the interface.

• I added code comments to the interceptor implementation to make it easier to understand.
• I added verification that objects returned by the framework are "enhanced".
• I upgraded to the latest release of HtmlUnitDriver (version 2.64.0)

Fix a bug with "rehydrated" SeleniumGrid objects

This release fixes a bug in the process of creating a SeleniumGrid object to represent a specified host URL. The URL itself wasn't being injected into the configuration, which could lead to subsequent NullPointerException failures.

Add iOS page class/test

In this release, I added a page model and test class for validating the XCUITestPlugin.

Add dependency context for PathUtils

In the previous release, I added a few calls to methods in the PathUtils class to code that gets used to launch Grid hub/node servers. What I failed to do was to add a dependency context entry so that the Java-Utils library this lives in gets added to the Grid server class path. This release takes care of that issue.

Set Java sub-process PATH; upgrade core dependencies

After all this time, I discovered that the default path inherited by Java processed spawned by CommandLine isn't always what might be hoped. This was causing trouble for Appium Grid nodes on Mac, which were unable to find the node executable as a result. I added a few new path-related functions in Java-Utils to provide a common oracle to solve this problem.

The new release of Java-Utils triggered a cascade of dependency bumps:

• Java-Utils → version 3.1.1
• Setting → version 3.0.2
• JUnit-Foundation → version 17.0.2
• TestND-Foundation → version 4.0.2-j8

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.