Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <50A36FE7.9020701@apache.org>
Date: Wed, 14 Nov 2012 10:18:15 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Subject: [NEWS] Oak news (6th edition)
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit


Hi,

Welcome to the 6th edition of the informal news on what's going on in Oak.

- Last week Jukka held a small workshop on Oak at the ApacheCon EU. 
There was some work on integrating the MongoDB based Microkernel with 
oak-run and enabling remote JCR access through DavEx. Although there was 
no formal presentation on Oak, a few people were asking about it and 
Jukka gave quick 5 min intros.

- Many new features, improvements and bug fixes have been contributed to 
the MongoDB based Microkernel through OAK-424. See also the respective 
pull request on GitHub to get a better overview: 
https://github.com/apache/jackrabbit-oak/pull/6

- In relation to the various Microkernel implementations we now have, we 
need to figure out how to best expose them for development, testing and 
continuous integration. See also OAK-434: Setup build profiles to run 
against either of the Microkernel implementations.

- The progress in the area of the Microkernel also sparked new 
discussions on how garbage collection could work for the data store. 
Currently there seem to be mainly two ideas worth further exploration: 
keep an index of references to binaries (kind of reference counting) and 
generational garbage collection. See OAK-377 for the issue and 
http://markmail.org/message/egmcpupjbbljno4j for the discussion.

- In Oak core some state tracking functionality has been pushed down 
from the Tree implementation to the NodeBuilder implementation. This 
greatly improves read/write performance but also has an impact on 
transient move operations, which are not tracked the same any more. See 
OAK-391 and http://markmail.org/message/b6dcyae362akyogd for the 
discussion and sample code demonstration the problem. Relevant issues:
   � OAK-413: TreeLocation.getStatus() cost increases as more content is 
read below this location
   � OAK-422: Replace PurgeListener in TreeImpl with NodeBuilder.reset()
   � OAK-417: Refactor/reimplement TreeImpl.getStatus and 
TreeImpl.getPropertyStatus to take advantage of the underlying NodeBuilder
   � OAK-418: Reduce/avoid re-resolving the underlying tree instances on 
every access in Item/Property/NodeDelegate

- The Oak JCR bindings saw many fixes, improvements and new features. 
Most notably we now have initial support for XML imports (OAK-127: 
Support for XML imports) and validation for node type management 
(OAK-411: Validator for node type management). Further improvements 
include:
   � OAK-395 : Inconsistency in Node#setProperty in case of null value
   � OAK-408: Add Definition for the root node
   � OAK-405: Node/Property getDefinition() returns first residual 
definition instead of matching named definition

- Since Apache Lucene does not provide OSGi bundles of their artefact, 
we decided to embed the Lucene dependency with Oak for the time being. 
The most transparent way to do so was through its own component 
"oak-lucene". See OAK-438: Provide the lucene index as an osgi bundle.

Michael