Hi, Replying here even though my answer concerns a number of messages on this thread.
Starting small with a single project is probably ok. If we are ready to split the project into multiple smaller projects later, ok. If we are not ready, then no. OSGi vs. non-OSGi... There are OSGi-zealots and anti-OSGi-zealots. So be it. Lets put it like this: People run an application in an OSGi framework and want to deploy Jackrabbit into it. They need OSGi-enabled/friendly Jackrabbit. There are people not running their application in an OSGi framework, they don't care for OSGi stuff - as long as Jackrabbit does not require OSGi to run. The good thing is: You can have both. Derby does it for example. So, I strongly suggest Jackrabbit 3 to be OSGi-enabled/friendly. Of course pluggable stuff must really be pluggable -- ACL functionality (login modules, access control managers, etc.) come to mind. This means real API separated package-wise from the implementations. So coming back to development modules. I think we should separate development and deployment ? We develop how we see fit ... in multiple modules (my preference) or in a single huge, monolithic project. The result of the development are artifacts and here we are free to create whatever level or modularization we or our users like. We can create a lot of small artifacts (libraries, bundles) or a single big one or both. Look at Groovy, they also do that. Just my $.02. Regards Felix Am Montag, den 29.11.2010, 14:01 +0000 schrieb Thomas Mueller: > I know the reasons for this are historical, and I don't want to change > things for Jackrabbit 2: Jackrabbit 2 consists of many distinct > projects. For me, this is just far too many, the complexity is > overwhelming even for me as a developer of Jackrabbit. I guess it's > even worse for users and potential committers. One project only > contains one(!) class. In some cases, the code for a feature are > spread into different projects. In one cases (that I know of), the > unit tests (not just integration tests) for a feature is in a > different project than the implementation. In my view, using the same > architecture for Jackrabbit 3 would make developing Jackrabbit 3 very > inefficient. It increases build time and makes code coverage results > partially meaningless. As we have seen multiple times, it is also a > pain for users, because he has to add multiple Jackrabbit jar files to > his project. There is a risk to combine Jackrabbit jar files that > don't work together. I don't know a similar projects that consists of > that many projects: Lucene is one project and jar file (lucene-core), > and Apache Derby, HSQLDB, and H2 are all one project. In my view, > splitting Jackrabbit 3 into multiple projects doesn't help anybody at > all (not the user, not the developer, and not the tester). > > > But for Jackrabbit 3, I suggest to keep all source "core" code in one > project, and create one jar file, until we have a good reason to split > it into multiple projects. > > > This excludes the TCK (Technology Compatibility Kit) of course, which > is a standalone project independent of Jackrabbit. It may also exclude > compatibility and performance tests, which are run against multiple > versions of Jackrabbit. As for remoting (RMI and DavEx) we may want to > re-use the existing Jackrabbit 2 projects, at least at the beginning, > or until we have better solutions. It may also exclude "utilities" > that are independent of the JCR implementation and that are not > required within Jackrabbit itself (but once Jackrabbit needs the > utility, it should be within Jackrabbit). What we do need to consider > is OSGi, but this doesn't mean we need to split the Jackrabbit core > *implementation* into multiple projects or jar files. > >
