jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject [jr3] Rethinking our Jackrabbit 3.0 roadmap
Date Mon, 22 Nov 2010 15:44:41 GMT

[This message from a few weeks ago apparently didn't reach @adobe.com
recipients, so I'm resending with my @gmail.com address. Apologies for
the duplication.]

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

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

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.



Jukka Zitting

View raw message