Hi Bilgin, many thanks for your review:
> There are some jars which already exists in the project Jap i deleted the duplicated libraries > I see also some interfaces and classes not used at all. HealthCheck, HealthCheckJackrabbit, DBAccess: First i thought they would nice to have, but at the current state they are unnecessary. Also the constants and JcrUtil interface. The JcrEventHandler should be an interface for content streaming (i.e. Image Streaming in the browser) that have to be implemented and is, from my point of view, not superfluous. > can we shorten this naming Yes of course we should > RepositoryAccess - may be change it to JcrRepositoryAccessor That is really a better name > There are tests which rely on the previous test to pass successfully. Yes the tests could be more straight forward, i will rewrite them > Dublicate code in JcrFileHelper getRepositoryContent method cleaned > What about creating a factory class that instantiates Could be a good point, but the interface to the developer should be the API classes (org.ofbiz.jcr.api). The problem i faced at this point was, that i have to deal with all these different content objects which i want to hide/ simplify for the developer so i created the api layer. This should be the first layer which knows which implementation of JCR is used. I think this can be optimized, so if you have another/better approach, we should talk about it. > Are there any changes to Content component, in the svn history there are > changes, but then I cannot see any? There where some changes in the content component, but i reverted them all. Because the first JCR implementation should be absolutely independent from the application module. (Except move tika libs from content component to framework jcr) Best Regards, Sascha -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
