Hi, Please see my comments inline.
Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Apr 28, 2010, at 6:37 AM, kelvin goodson wrote: > 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 interfacedef.java should be SPI. We use java interface models in many modules. > implementation.spring uses implementation.java implementation.spring extends implementation.java to some extent. We adds the SCA annotation support for Spring. Some potential refactoring could happen to extract the common base for all POJO based implementation types. > binding-atom-runtime depends on binding-http binding-atom-runtime is built on top of binding-http. It's a specialization. > jms-runtime dependence on binding.ws Not sure. > jms-runtime dependence on databinding-xml We may be able to refactor the code to use the databinding Mediator SPI instead of the specific transformer classes. > jsonrpc-provider & runtime dependency on interface-java > rmi-runtime depends on interface-java Again, interface-java should be SPI. > binding-ws-wsdlgen depends on databinding.jaxb We have cases that some modules are friends. We can view them as internal SPIs. > binding-ws dependends on interfacedef.wsdl interface-wsdl should be SPI. > interfacef-java-jaxws depends on interfacedef.java interface-java-jaxws is the specialization of interface-java. > databinding.axiom and db.json depends on databinding.javabeans Some transformers deal with multiple databindings. > > 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
