Hi Chemistry,
in the past weeks I have done some work with query integration. Currently all is part of the InMemory server, but I will move the reusable parts to the server-support package and a documentation page to the wiki. There is one problem remaining: As discussed in CMIS-212 I have managed to separate the CMIS core grammar from the proposed set of extensions. This also is a nice pattern for others who want to extend the grammar. The "composite grammars" seems to be relatively new feature in ANTLR, not being 100% mature. With some trial and error I got this working, but there is one drawback. The gunit test framework is currently incompatible with composite grammars, all tests result in a ClassNotFoundException. I tracked this down and this is caused by some reflection magic in the test framework. The code that generates the method names to call the parser is incorrect for composite grammars and hard coded. I also tried to upgrade ANTLR to 3.2 but it did not help. Another disadvantage of composite grammars is that the generated Java code is more difficult to read. Now we have two ways to resolve this: 1) Duplicated grammars with having some redundant rules and use gunit 2) I have worked around this bug and now can do the same in a junit test. The tests then don't have such a nice syntax but basically it is the same. This would let us get rid of the gunit dependency. I have adapted all available tests and a few new ones. Instead of: "123.345E78" OK " SELECT * FROM WHITE_PAPER" -> (SELECT * (FROM (TABLE WHITE_PAPER))) Your will now have @Test public void testQuery () throws Exception { testParserOk("literal", "123.345E78"); testParser("query", "SELECT * FROM WHITE_PAPER", "(SELECT * (FROM (TABLE WHITE_PAPER)))"); } I am happy with both approaches. If there are no comments I will continue with 2).2) integrates better with Java and our remaining test framework. As the CMIS grammar is not overly complex 1 is not a big deal either. But for example the full text part (being still a todo) needs to be done twice. The reusable part for query integration also needs access to the type system. Therefore a dependency on a type manager is introduced. This is still on our TODO-list in https://issues.apache.org/jira/browse/CMIS-196. I have added in the supported manager an interface called "TypeManager" that is implemented in the inmemory server. This is nothing but a placeholder until we get a real type manager. There are only very few methods needed for query support. Jens