jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jzitt...@adobe.com>
Subject [jr3] Rethinking our Jackrabbit 3.0 roadmap
Date Wed, 03 Nov 2010 13:30:57 GMT

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

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.



Jukka Zitting
View raw message