Hi, Thanks.
Am 06.03.2012 um 04:00 schrieb Jukka Zitting: > Hi, > > On Tue, Mar 6, 2012 at 9:17 AM, Jukka Zitting <[email protected]> wrote: >> Oak has the advantage and so we'll go with that. I'll set up the new >> mailing list, issue tracker and svn space in a moment. > > The issue tracker is now available at > https://issues.apache.org/jira/browse/OAK and the svn space is at > http://svn.apache.org/repos/asf/jackrabbit/oak/ (I'll set up a Git > mirror later today). The oak-dev@ mailing list should follow up > shortly, see INFRA-4514 [1]. > > To get us started, I'll set up a basic multimodule build in oak/trunk > along the lines of what we have in jackrabbit/trunk. As initial > components I propose the following: > > * oak-core, for the main codebase (incl. unit tests) > * oak-run, for a runnable jar packaging > * oak-it, for integration tests > * oak-bench, for performance tests If we assume a modular piece of code, just having oak-core proably goes in the wrong direction. At least I would factor out anything that would be something like a plugin or extension API, like the Mikrokernel API itself. Regards Felix > > We'll start building the Oak codebase under org.apache.jackrabbit.oak > in oak-core. To avoid having to start from scratch, I propose that we > copy the existing MK work from org.apache.jackrabbit.mk to under > oak-core and gradually clean up and refactor relevant parts of the > codebase to subpackages under o.a.j.oak. Other existing code from > above the MK should probably treated similarly. > > [1] https://issues.apache.org/jira/browse/INFRA-4514 > > BR, > > Jukka Zitting
