Hi, On Jan 14, 2008 10:28 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Sonntag, den 13.01.2008, 16:21 +0200 schrieb Jukka Zitting: > > JCR (the current Jira project) > > [...] > > Wow ! I think this should still be split:
I don't see how you could end up with a manageable number of subprojects if you want to split down this one. I used the vague number of past cross-component issues as a way to group things together, and this core cluster came up as the most interdependent set of components. We probably should strive to split it down at some point, but only after we've first done the required refactoring work. As mentioned in my previous message, I want our codebase to drive the organizational boundaries, not the other way around. > * jackrabbit-jcr-commons: Is very much API like, so we could move it > to the API cluster, right ? Not really. There's lots of implementation classes (with implementation bugs) there and traditionally the component has been tightly coupled with jackrabbit-core. Much of it's original contents (the name, util, uuid, and value packages) are essentially just parts of jackrabbit-core that could be extracted to a separate component due to having no dependencies to other parts of the core. I think much of that code is much better located in spi-commons where it actually can and will be reused by multiple backends. The new stuff in o.a.j.commons has IMHO a clearer architectural separation to jackrabbit-core and thus could warrant separate releases, but until we have deprecated and removed the rest of the component I don't think we should take separate jcr-commons too far from core. > * jackrabbit-spi-commons, -jcr2spi, -spi2jcr: These are the SPI > cluster I was actually even considering including jackrabbit-spi in the core cluster as an internal component until it's more stabilized (at some point we need to start considering backwards compatibility for all spi changes). The spi implementation components (at least spi-commons and jcr2spi) are code-wise quite related to core and jcr-commons, and quite recently we were still moving large chunks of code between these components. I don't think we've yet reached an architecturally stable componentization there and we still should make core depend on jcr2spi to avoid duplicate code, so IMHO it's premature to split these SPI components to a separate subproject. > * jackrabbit-classloader: There isn't much work going on here, apart > from bugfixing. So there will be no reasons for new releases ! Even bug fixes need to be released. Are you suggesting we just drop the component? > * jackrabbit-text-extractors: Is this a movable target ? Otherwise, I > don't see much release work here ... We need to keep text-extractors around until we can replace the functionality with Apache Tika or something like that. We had one change (JCR-1247) to text-extractors in 1.4, and there might well be bug fixes or other minor changes that we need to do before we can drop the component. > * jackrabbit-jcr-tests: Some fixes now and then ... I would make this > a separate cluster Quite a few actually, jcr-tests is one of our more actively developed components. Architecturally it would warrant it's own subproject (like JCRTCK), but I pooled it in the core project to keep the number of subprojects manageable. There is also little end-user demand for jcr-tests. But yes, if we want to split down the core JCR subproject, I would first go with JCRTCK and only after that start considering any other splittings. > > JCRWEB > > I would separate these, too: -jcr-server and -webdav in one cluster, > -jcr-servlet and -webapp in another one. That may make sense architecturally, but again we should keep the number of subprojects down to a manageable level. BR, Jukka Zitting
