Hi, We have lots of good ideas on what to do in Jackrabbit 3.0, but such major changes will likely require years of effort unless we can attract lots of extra contributors. Meanwhile we'll need to live with incremental improvements to our already reasonably good and stable 2.x codebase.
Unfortunately there's quite a bit of old baggage from 1.x in the 2.x codebase. For example all our non-bundle PMs (see JCR-2802) put a backwards compatibility load on the internal PersistenceManager interface, which significantly reduces our ability to improve things. For example, if we didn't have non-bundle PMs, we could easily get rid of an entire caching layer by merging the bundle and shared item state caches. There are a lot of other potential mid-term changes that may need backwards-incompatible upgrades. For example things like a more flexible repository configuration mechanism (think of /jcr:system/rep:config), storing search indexes inside the repository, or the potential OSGification of Jackrabbit. We could move forward on all of these already before the 3.0 release as currently planned, but doing so in a minor release would require extensive backwards-compatibility work. Thus I think it would be a good idea to rethink our roadmap for Jackrabbit 3.0. Instead of planning for a big rewrite like the one that's currently being discussed, I'd like to go for a more incremental 3.0 roadmap that includes only a few bigger changes like the ones mentioned above. Such a release could realistically be achieved already next year and would already bring some major improvements to our users. We could still work in a development branch for a bigger architectural rewrite and call that Jackrabbit NG (or something similar) until it's ready to be released as the next major Jackrabbit x.0 release. Such a plan should also make the eventual upgrade to Jackrabbit NG smoother, as we'd then no longer need to worry about migration from things like non-bundle persistence, etc. WDYT? BR, Jukka Zitting
