Hi,
Last week has been pretty busy with the Oak Hackathon on Tuesday followed by the .adaptTo 2012 conference (http://adaptto.mixxt.de/) Wednesday to Friday in Berlin.
* The Hackathon (http://wiki.apache.org/jackrabbit/Oak%20Hackathon%20September%202012) was quite a success even though not too much hacking has actually taken place. Half of the roughly 10 attendees where new to the project so we decided to turn this more into an intro session. Jukka and Michael gave a preview on their Oak presentation for .adaptTo 2012 (http://goo.gl/7fikE) and Jukka went through some coding examples showing how to write a custom commit hook for Oak. The code examples will become parts of the NodeState model documentation. See https://github.com/apache/jackrabbit-oak/blob/trunk/doc/nodestate.md. We briefly discussed about repeating this kind of event and I think we agreed that this would be a good thing. I will follow up in a separate thread to sort out the details regarding time frame and location.
* Jukka's and Michael's presentation "Jackrabbit Oak - the next generation content repository" (http://goo.gl/7fikE) generated quite some interest at .adaptTo 2012. Most questions revolved around issues related to backward compatibility, better scalability in cluster deployments and the impact of snapshot isolation.
* The documentation on the NodeState has further evolved. Most notably there is a new section on how to build new node states using the node state builder. See https://github.com/apache/jackrabbit-oak/blob/trunk/doc/nodestate.md.
(Note that the Github mirror lags a bit behind. So if the relevant content is not their yet use this svn link: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/doc/nodestate.md?view=markup)
* Last week's testing resulted in a flurry of filed issues on the QueryEngine parsing and interpretation of results. We uncovered some inconsistencies on node type handling (OAK-325), full text condition parsing(OAK-), like on path constraints (OAK-347) and a bunch of JCR functions that are not supported yet in Oak (excerpt, defer, similar, eq). As work on the query engine itself stabilises there is a bit of advance happening on the custom query index side: Lucene is chugging along nicely (OAK-340, OAK-334), and more interestingly we have a Solr integration up for review at OAK-307, take a look if interested! A gentle reminder, the main JIRA issue that tracks query related problems and inconsistencies compared to jackrabbit is OAK-237.
* Tudor Rogoz contributed an initial version of a performance test suite for the Microkernel which can be used for benchmarking the various implementations we have. We envision to use this also for scalability testing of cluster deployments further down the line. See OAK-335 for the respective JIRA issue and http://svn.apache.org/viewvc?rev=1392315&view=rev for the contributions itself.
* With the resolution of OAK-197 there are some minor changes in the Oak API: the ConflictHandler argument was removed from the Root.commit() and Root.rebase() methods. We figured that these parameters unnecessarily complicate the client API and break encapsulation and thus decided to move the conflict handling logic to a plugin instead of exposing it this way through the API.
* In revision 1392352 (http://svn.apache.org/viewvc?rev=1392352&view=rev) Marcel moved the repository setup code from ContentRepositoryImpl and ContentSessionImpl to its own plugin InitialContent. The refactored OSGi related classes allow to hook this directly into the life cycle of the Microkernel.
* On the debating side there was a discussion on whether and how we want to support virtual content in Oak (http://markmail.org/message/3fpssbdv6srabwx6). Not much progress so far but I expect this to be a topic which will pop up rather sooner again than later. A further - rather lengthy debate - was on custom index configuration (http://markmail.org/message/bdgi77dd6wy2hkbp). As far as I could follow it was mainly about whether to store the index (configurations) centrally or locally with the content. While we currently don't have an implementation for the non centralised case, I think we can expect some experimental ones soon. This will probably allow us to make a better informed decision on which way(s) to go. Also there was a discussion to go beyond mere path base access in the Microkernel (http://markmail.org/message/vwq22osa7q2anm33). The motivations for bringing this up was that path based access doesn't seem to scale too well in the MongoDB based implementation. Finally a rather recent discussion is concerned about the destiny of Oak (http://markmail.org/message/ga4mn2x2xqsvzwg6) and is all about whether Oak should graduate into its own project or become Jackrabbit 3.0 replacing the current Jackrabbit trunk. While the discussion is still ongoing most of the opinions raised so far seem to be in favour of the 2nd option.
Thanks to Alex for providing the query/indexing section of this write up. cheers, Michael
