We have come to a clearly understanding of the service registry pattern based on inspection of the Sesame code base and the java.util.ServiceLoader class. This pattern is sufficient for declaring new service providers, such as the NQuadsParser, but does not provide any mechanism for replacing existing service providers for the same "key". In particular, it appears likely that the service providers are registered in something like their classpath ordering. This means that we can not rely on this META-INF/services pattern to replace the Sesame RDF/XML parser with our own. This implies that we need to intervene in one or more locations and ensure that the Sesame RDF/XML parser is replaced by our RDF/XML parser (which supports SIDs and statement enum interchange). (The alternative is to register our parser under a new MIME type, which would be a different key. However, that leads to problems where our version of the parser is not used before the RDF/XML is not appropriately marked with the extension MIME type.)
The SPARQL parser does not have these problems because we explicitly create an instance without use of the service registry pattern. Also, the Bigdata2ASTSPARQLParser class does not have a zero argument constructor (it requires a reference to the database) and is therefore not compatible with the service registry pattern.
I have added a META-INF/services declaration for the NQuadsParser, an NQuadsParserFactory, and a test suite to verify the ability to resolve an NQuadsParserFactory and NQuadsParser using the service provider pattern. I commented out the code in the static initialization of NQuadsParser which was responsible for registering the NQuadsParser's inner parser factory class. I verified that resolution now takes place through the service provider pattern in the IDE when the META-INF directory structure is part of the classpath. The nquads support has been moved into the com.bigdata.rdf.rio.nquads package to follow the general package naming pattern for rio/openrdf.
The bigdata RDF/XML parser has been moved to the com.bigdata.rdf.rio.rdfxml package and various package private classes have been imported to support the parser since they are no longer visible now that the package namespace has changed. The RDF/XML parser/write classes have also been renamed to begin "Bigdata" so there can no longer be any confusion about which parser/writer is being used. A Bigdata RDF/XML writer factory class has been added. META-INF/services entries have been added for the RDF/XML parser/writer, but as noted above, those entries are NOT sufficient to guarantee resolution of the correct service provider.
com.bigdata.rdf.ServiceProviderHook has been added. The NQuadsParser#forceLoad() method has been refactored into ServiceProviderHook which is used to enforce certain overrides (replacements) of the default services registered by Sesame. This also ensures that RDFFormats declared by bigdata are registered with openrdf (notably the NQUADS format).
I modified several places in the bigdata code base where we were directly using the bigdata specific RDFXMLWriter or RDFXMLParser to use the service registry mechanism instead (since the class names were changed, the hard coded references were picking up the wrong class). When those places were in the test suite, I added asserts to verify that the bigdata extension classes were being used.
The "compile" target in build.xml has been modified to also copy the META-INF/services directory for the bigdata-rdf package. I have verified the "compile" target causes the output META-INF directory to contain all of the desired META-INF/services files.
The TestLocalTripleStore and TestBigdataSailWithQuads test suites are green.
The next step is to refactor the SPARQL parser classes in order to avoid similar class path problems arising from using the same package name as openrdf. After than I will open up the SPARQL grammar for changes to support property paths and UPDATE (under different tickets).
Committed Revision r6045.