Problem:
Under the covers the maven selenium:selenese task uses the HTMLLauncher to run selenese tests on the local filesystem. This works because the HTMLLauncher calls the addNewStaticContent(File) method on SeleinumServer to register the test directory. The addNewStaticContent method creates an instance of FsResourceLocator and adds it to the StaticContentHandler. The end result is the selenium RC proxy functionality injects the static file content at selenium-server/tests/*. Therefore the selenium test runner from selenium core is able to find and run the test suite the maven selenium:selense task is pointed at.

Unfortunately, none of this functionality is available when one starts the selenum RC server using maven's selenium:start-server goal. This means one must ensure the selenese tests are somehow served up by the application server being tested. This results in a situation which is less convenient and frequently less DRY than it could be; as the selenese test content used by the maven selenium:selenese task can easily become out of sync with the source version of the selenese test content.

==========================================
Proposed Solution:
This problem should be solvable by having the selenium:start-server goal register a ResourceLocator implementation smart enough to detect file changes which occur at runtime. (The FsResourceLocator may already do this, I haven't looked that closely.) To cleanly expose the necessary functionality to the maven selenium plugin will likely require a few minor changes within the selenium RC code.

==========================================
Workaround:
To workaround the problem for now I intend to do the following:

1) Create a maven module which produces a war with nothing other than the selenese tests.
2) Configure my functional-tests maven module to use the dependency plugin to expand the selenese tasks somewhere in the target directory in a phase prior to the phase I bind the selenium:selenese goal to. The selenium:selenese goal will be configured to pick up the selenese tests from the target directory in which the dependency plugin expanded them.
3) Configure the cargo plugin to co-deploy the war with the selenese tests alongside my application's war file. This will allow a developer to manually run the selenese tests.

Note: The selenium, dependency and cargo plugins are all configured in my functional-tests module.