The current ServiceLoader implementation makes it difficult (if not impossible) to extend an SPI implementation and have it take precedence over an implementation already on the classpath. In other words, it discourages being able to use an implementation as a library dependency.

The reason this happens is because the original implementation provides a ServiceLoader activation file under META-INF/services. This conflicts with the activation file used by the extended implementation in the case that Arquillian is looking for exactly one implementation. The only way to work around this at the moment is to copy all of the classes required by the original implementation into your own project, extend (or modify) the original implementation class, and package those classes with a service activation file. In effect, you have removed the original activation file and replaced it with your own.

Clearly what is missing is a mechanism to veto the original implementation. You know you which implementation you want and which one you don't want. So, in the activation file you simply mark the original implementation as vetoed (to reverse the effect of it being specified as an implementation). An implementation class would be vetoed by prefixing it with a ! symbol.

!org.jboss.arquillian.container.jbossas.remote_6.JBossASRemoteContainer
com.acme.arquillian.container.jbossas.remote_6.AcmeJBossASRemoteContainer

While this may seem very specific as you are referencing an implementation class, that's the whole point because your Java code is extending that class. It's about library reuse, so you don't have to import the entire package just to exclude the activation file.

Frankly, I feel like this is a critical missing piece in the JDK ServiceLoader model in general. It's like providing a light switch that only turns on, not off. Or a radio button with only one option. Once you press it, you can't unpress it.