I've been looking at the extension code we have, to try to understand by reverse engineering, what might be considered SPIs that are available to an extension developer. I've just finished a pass through the extension code, marking the classes that each extension directly depends on as extension spi. (Some results at [1]) Some of this was clear cut, but other dependencies were not so clear to categorize. In particular, some extensions depend on others, and it wasn't clear to me whether there are a set of core extensions that can be considered to contain SPI, whether there are a set of special relationships between some extensions or whether there are code tangles that ought to be unravelled. I suspect there is a combination of all three.
Below are some examples. If anyone can offer an insights as to whether these relationships suggest that the dependencies should be marked as extension SPI I'd be very grateful. implementation.web and implementation.widget use interfacedef.java implementation.spring uses implementation.java binding-atom-runtime depends on binding-http jms-runtime dependence on binding.ws jms-runtime dependence on databinding-xml jsonrpc-provider & runtime dependency on interface-java rmi-runtime depends on interface-java binding-ws-wsdlgen depends on databinding.jaxb binding-ws dependends on interfacedef.wsdl interfacef-java-jaxws depends on interfacedef.java databinding.axiom and db.json depends on databinding.javabeans I've also currently skipped binding-sca-runtime, as it wasn't clear to me whether this was a special extension that was itself SPI or whether it should be treated as all the rest. Kelvin [1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SPI+Investigations
