Am Montag, den 14.01.2008, 12:52 +0200 schrieb Jukka Zitting: > 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.
After all these words I have to come to the conclusion, that all this code looks somewhat convoluted ... So, we have to keep this cluster ... > > > * 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? Definitely not, there will be bugfixes and we will not drop this. But we should certainly not raise the version number and create new releases just for fun. I would say the classloader component is largely in maintenance mode at the moment. > > > * 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. By "movable target" I meant: This is probably in maintenance mode just like the class loader. Of course, if there were changes to this before the latest release, there is a new version released. But same as with class loader, no release and version number incrementing just for fun. > > > * 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. ACK. > > > > 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. Again: No changes, no release, no management. Therefore we should strive for this separation. Regards Felix
