You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2012/10/23 16:03:04 UTC
Roadmap for Jackrabbit 2.x and 3.0
Hi,
On oak-dev@ we were just discussing about the future of Oak and how
it'll relate to Jackrabbit in general. The emerging consensus seems to
be that we should keep Oak as a part of Jackrabbit and have Jackrabbit
3.0 be based on Oak.
Here's an early draft of how this could work out in terms of the
Jackrabbit roadmap:
* Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0
version sometime around the end of this year. As usual, we'll have a
2.6 maintenance branch for upcoming 2.6.x patch releases.
* Jackrabbit 2.x: Just after branching 2.6, we'd create a separate 2.x
development branch for future work based on the current Jackrabbit
architecture. This branch would give us a chance to more than just bug
fixes on the 2.x codebase for at least a few more years until everyone
is comfortable upgrading to an Oak-based repository.
* JCR 2.1 RI: The 2.x branch could also be used for developing the
reference implementation for JSR 333 (JCR 2.1). Given current
schedules this could become something like Jackrabbit 2.8.
* Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
been created, we'd replace the current trunk with an Oak-based JCR
implementation. This "Blackrabbit" edition of Oak would come with a
set of plugin components designed to offer as much backwards
compatibility with existing Jackrabbit 2.x deployments as possible,
and would ship with code that can automatically migrate or upgrade an
existing Jackrabbit 2.x repository. The target date for Jackrabbit 3.0
would be sometime next year, with focus on stability and backwards
compatibility.
* Jackrabbit 3.x: After Jackrabbit 3.0 is out we can continue working
on things like performance and scalability, integrations with
different backends and clients, and new features for future Jackrabbit
3.x releases. And since Jackrabbit 3.0 will be based on a fresh new
underlying architecture from Oak, it's likely that we'll encounter a
number of smaller issues to be fixed or improved.
WDYT?
[1] http://markmail.org/message/ga4mn2x2xqsvzwg6
BR,
Jukka Zitting
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Bart van der Schans <b....@onehippo.com>.
I like it ;-)
+1
Bart
On Tue, Oct 23, 2012 at 4:03 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On oak-dev@ we were just discussing about the future of Oak and how
> it'll relate to Jackrabbit in general. The emerging consensus seems to
> be that we should keep Oak as a part of Jackrabbit and have Jackrabbit
> 3.0 be based on Oak.
>
> Here's an early draft of how this could work out in terms of the
> Jackrabbit roadmap:
>
> * Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0
> version sometime around the end of this year. As usual, we'll have a
> 2.6 maintenance branch for upcoming 2.6.x patch releases.
>
> * Jackrabbit 2.x: Just after branching 2.6, we'd create a separate 2.x
> development branch for future work based on the current Jackrabbit
> architecture. This branch would give us a chance to more than just bug
> fixes on the 2.x codebase for at least a few more years until everyone
> is comfortable upgrading to an Oak-based repository.
>
> * JCR 2.1 RI: The 2.x branch could also be used for developing the
> reference implementation for JSR 333 (JCR 2.1). Given current
> schedules this could become something like Jackrabbit 2.8.
>
> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
> been created, we'd replace the current trunk with an Oak-based JCR
> implementation. This "Blackrabbit" edition of Oak would come with a
> set of plugin components designed to offer as much backwards
> compatibility with existing Jackrabbit 2.x deployments as possible,
> and would ship with code that can automatically migrate or upgrade an
> existing Jackrabbit 2.x repository. The target date for Jackrabbit 3.0
> would be sometime next year, with focus on stability and backwards
> compatibility.
>
> * Jackrabbit 3.x: After Jackrabbit 3.0 is out we can continue working
> on things like performance and scalability, integrations with
> different backends and clients, and new features for future Jackrabbit
> 3.x releases. And since Jackrabbit 3.0 will be based on a fresh new
> underlying architecture from Oak, it's likely that we'll encounter a
> number of smaller issues to be fixed or improved.
>
> WDYT?
>
> [1] http://markmail.org/message/ga4mn2x2xqsvzwg6
>
> BR,
>
> Jukka Zitting
--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
AW: Roadmap for Jackrabbit 2.x and 3.0
Posted by KÖLL Claus <C....@TIROL.GV.AT>.
Hi ...
Sounds very good to me :-)
greets
claus
RE: Roadmap for Jackrabbit 2.x and 3.0
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
> g) Or as a last resort, abandon the idea of a joint deployment
> package. Jackrabbit Classic and Oak would be shipped in separate
> deployment artifacts.
this is my preferred option. this would also send out the message that
Oak is meant to replace Jackrabbit 2.x.
I'd keep the Jackrabbit 2.x line for maintenance purpose and either
release 2.8.x bugfix releases in the future or if needed a 2.10 and so
on...
For Oak I'd either release it as Oak 1.0 or Jackrabbit 3.0. But neither
would contain any legacy code from Jackrabbit 2.x, except maybe
for migration purposes.
Regards
Marcel
AW: Roadmap for Jackrabbit 2.x and 3.0
Posted by KÖLL Claus <C....@TIROL.GV.AT>.
Hi,
>c) Ship the jackrabbit deployment packages without Lucene integration
>for Oak. This would allow people to start playing with Oak in their
>existing deployments, but require some deployment changes for full Oak
>functionality.
+1 I think this could be a way ...
>f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
>container, and use it to selectively deploy the required
>implementation components, including the correct version of Lucene.
As we use jackrabbit as a JCA Adapter I don't know if this could be a problem ...
>g) Or as a last resort, abandon the idea of a joint deployment
>package. Jackrabbit Classic and Oak would be shipped in separate
>deployment artifacts.
Hmm I would like to see only one jackrabbit. Jackrabbit 3.0 should be the next step forward and
users should not care about which kernel is inside or not. It would be great if there are steps described to upgrade
or the upgrade process comes out of the box.
greets
claus
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Jan 15, 2014 at 1:35 PM, Jukka Zitting <ju...@gmail.com> wrote:
> I'm thinking of trying to implement one or two of these alternatives
> within the next few weeks, and cut Jackrabbit 2.8 based on that work
> and including something like Oak 0.16 as a beta feature. Assuming that
> approach works and Oak stabilizes as planned, we could then follow up
> with Jackrabbit 3.0 fairly soon after 2.8.
None of the alternatives looked too good, so I think the best approach
for now is to go with the fallback option g) of keeping the Oak and
Jackrabbit Classic deployment packages separate for now.
Based on that I already laid out a plan for an Oak 1.0 release [1] and
in parallel we should proceed to cut a stable Jackrabbit 2.8 release
(release plan to follow). Once those releases are out, we can revisit
the plan for a unified Jackrabbit 3.0 release.
[1] http://markmail.org/message/6kkkdmyf6ni5pgte
BR,
Jukka Zitting
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Felix Meschberger <fm...@adobe.com>.
Am 17.01.2014 um 11:01 schrieb Bertrand Delacretaz <bd...@apache.org>:
> On Wed, Jan 15, 2014 at 7:35 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> g) ...Or as a last resort, abandon the idea of a joint deployment
>> package. Jackrabbit Classic and Oak would be shipped in separate
>> deployment artifacts....
>
> Does this have impact on how people can migrate existing Jackrabbit
> repositories to Oak, or is migration a separate concern and plan?
Yes, please !
Regards
Felix
>
> -Bertrand
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jan 15, 2014 at 7:35 PM, Jukka Zitting <ju...@gmail.com> wrote:
> g) ...Or as a last resort, abandon the idea of a joint deployment
> package. Jackrabbit Classic and Oak would be shipped in separate
> deployment artifacts....
Does this have impact on how people can migrate existing Jackrabbit
repositories to Oak, or is migration a separate concern and plan?
-Bertrand
Re: Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by "zhouhuakang459@gmail.com" <zh...@gmail.com>.
Sorry for disturbing you,i want to know that does the jackrabbit support the android now or in the future?
zhouhuakang459@gmail.com
From: Michael Dürig
Date: 2014-01-16 16:51
To: dev
Subject: Re: Roadmap for Jackrabbit 2.x and 3.0
On 15.1.14 7:35 , Jukka Zitting wrote:
> Hi,
>
> a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier
> (http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard,
> and it's questionable whether the benefits are worth the effort.
-0, too little benefit for the effort it would take.
>
> b) Downgrade Oak to use Lucene 3. This should be doable with not much
> effort, as the Lucene integration in Oak is much simpler than in
> Jackrabbit Classic. It might even be possible to make oak-lucene
> version-independent, so it would work with both Lucene 3 and 4.
-1, people will start bugging us about upgrading to Lucene 4 as soon as
Oak is out.
>
> c) Ship the jackrabbit deployment packages without Lucene integration
> for Oak. This would allow people to start playing with Oak in their
> existing deployments, but require some deployment changes for full Oak
> functionality.
+0, not sure how much this degrades the actual value of the deployment
packages though.
>
> d) Use the class rewriting tricks in something like the Shade plugin
> [1] to be able to include both Lucene 3 *and* 4 in the same deployment
> packages. I'm not sure if this is even possible with Lucene, or how
> much effort it would require.
>
> e) Use a custom classloader setup to load the correct version of
> Lucene depending on the selected Jackrabbit mode.
-10^12, and spend the rest of our lives debugging all kinds of weird
class loading issues in each and every deployment container ;-)
>
> f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
> container, and use it to selectively deploy the required
> implementation components, including the correct version of Lucene.
+1 if we have a strong argument for going with the combined deployment
option.
>
> g) Or as a last resort, abandon the idea of a joint deployment
> package. Jackrabbit Classic and Oak would be shipped in separate
> deployment artifacts.
+1 for its simplicity otherwise.
Michael
>
> I'm thinking of trying to implement one or two of these alternatives
> within the next few weeks, and cut Jackrabbit 2.8 based on that work
> and including something like Oak 0.16 as a beta feature. Assuming that
> approach works and Oak stabilizes as planned, we could then follow up
> with Jackrabbit 3.0 fairly soon after 2.8.
>
> [1] http://maven.apache.org/plugins/maven-shade-plugin/
>
> BR,
>
> Jukka Zitting
>
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Torgeir Veimo <to...@gmail.com>.
Is there a guide for how to migrate from jackrabbit 2.* to oak?
On 16 January 2014 18:51, Michael Dürig <md...@apache.org> wrote:
>
>
> On 15.1.14 7:35 , Jukka Zitting wrote:
>>
>> Hi,
>>
>>
>> a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier
>> (http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard,
>> and it's questionable whether the benefits are worth the effort.
>
>
> -0, too little benefit for the effort it would take.
>
>
>>
>> b) Downgrade Oak to use Lucene 3. This should be doable with not much
>> effort, as the Lucene integration in Oak is much simpler than in
>> Jackrabbit Classic. It might even be possible to make oak-lucene
>> version-independent, so it would work with both Lucene 3 and 4.
>
>
> -1, people will start bugging us about upgrading to Lucene 4 as soon as Oak
> is out.
>
>
>>
>> c) Ship the jackrabbit deployment packages without Lucene integration
>> for Oak. This would allow people to start playing with Oak in their
>> existing deployments, but require some deployment changes for full Oak
>> functionality.
>
>
> +0, not sure how much this degrades the actual value of the deployment
> packages though.
>
>
>>
>> d) Use the class rewriting tricks in something like the Shade plugin
>> [1] to be able to include both Lucene 3 *and* 4 in the same deployment
>> packages. I'm not sure if this is even possible with Lucene, or how
>> much effort it would require.
>>
>> e) Use a custom classloader setup to load the correct version of
>> Lucene depending on the selected Jackrabbit mode.
>
>
> -10^12, and spend the rest of our lives debugging all kinds of weird class
> loading issues in each and every deployment container ;-)
>
>
>>
>> f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
>> container, and use it to selectively deploy the required
>> implementation components, including the correct version of Lucene.
>
>
> +1 if we have a strong argument for going with the combined deployment
> option.
>
>
>>
>> g) Or as a last resort, abandon the idea of a joint deployment
>> package. Jackrabbit Classic and Oak would be shipped in separate
>> deployment artifacts.
>
>
> +1 for its simplicity otherwise.
>
> Michael
>
>
>>
>> I'm thinking of trying to implement one or two of these alternatives
>> within the next few weeks, and cut Jackrabbit 2.8 based on that work
>> and including something like Oak 0.16 as a beta feature. Assuming that
>> approach works and Oak stabilizes as planned, we could then follow up
>> with Jackrabbit 3.0 fairly soon after 2.8.
>>
>> [1] http://maven.apache.org/plugins/maven-shade-plugin/
>>
>> BR,
>>
>> Jukka Zitting
>>
>
--
-Tor
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Michael Dürig <md...@apache.org>.
On 15.1.14 7:35 , Jukka Zitting wrote:
> Hi,
>
> a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier
> (http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard,
> and it's questionable whether the benefits are worth the effort.
-0, too little benefit for the effort it would take.
>
> b) Downgrade Oak to use Lucene 3. This should be doable with not much
> effort, as the Lucene integration in Oak is much simpler than in
> Jackrabbit Classic. It might even be possible to make oak-lucene
> version-independent, so it would work with both Lucene 3 and 4.
-1, people will start bugging us about upgrading to Lucene 4 as soon as
Oak is out.
>
> c) Ship the jackrabbit deployment packages without Lucene integration
> for Oak. This would allow people to start playing with Oak in their
> existing deployments, but require some deployment changes for full Oak
> functionality.
+0, not sure how much this degrades the actual value of the deployment
packages though.
>
> d) Use the class rewriting tricks in something like the Shade plugin
> [1] to be able to include both Lucene 3 *and* 4 in the same deployment
> packages. I'm not sure if this is even possible with Lucene, or how
> much effort it would require.
>
> e) Use a custom classloader setup to load the correct version of
> Lucene depending on the selected Jackrabbit mode.
-10^12, and spend the rest of our lives debugging all kinds of weird
class loading issues in each and every deployment container ;-)
>
> f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
> container, and use it to selectively deploy the required
> implementation components, including the correct version of Lucene.
+1 if we have a strong argument for going with the combined deployment
option.
>
> g) Or as a last resort, abandon the idea of a joint deployment
> package. Jackrabbit Classic and Oak would be shipped in separate
> deployment artifacts.
+1 for its simplicity otherwise.
Michael
>
> I'm thinking of trying to implement one or two of these alternatives
> within the next few weeks, and cut Jackrabbit 2.8 based on that work
> and including something like Oak 0.16 as a beta feature. Assuming that
> approach works and Oak stabilizes as planned, we could then follow up
> with Jackrabbit 3.0 fairly soon after 2.8.
>
> [1] http://maven.apache.org/plugins/maven-shade-plugin/
>
> BR,
>
> Jukka Zitting
>
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
While (f-OSGi) has an appeal to me and think should be done in any case, I would think (g-separate) is the right way to go to prevent complexity with IMVHO little benefit.
Just my CHF 0.05
Regards
Felix
Am 15.01.2014 um 12:35 schrieb Jukka Zitting <ju...@gmail.com>:
> Hi,
>
> Let's pick this up again!
>
> On Thu, Jan 17, 2013 at 6:00 AM, Jukka Zitting <ju...@gmail.com> wrote:
>>> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
>>> been created, we'd replace the current trunk with an Oak-based JCR
>>> implementation.
>>
>> As mentioned above, instead of replacing the trunk entirely, I'd keep
>> both codebases in trunk for now and include *both* the 2.x and Oak
>> repositories in things like jackrabbit-webapp and
>> jackrabbit-standalone, with a configuration option to decide which
>> repository implementation should be used in each particular
>> deployment.
>
> I was looking at this a few months ago, and there's one big blocker
> that makes such a double deployment somewhat complicated: Since
> Jackrabbit 2.x ("Jackrabbit Classic"?) still uses an older version of
> Lucene, it's hard merge with Oak where Lucene 4 is used. I have a few
> ideas on how this problem could be resolved:
>
> a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier
> (http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard,
> and it's questionable whether the benefits are worth the effort.
>
> b) Downgrade Oak to use Lucene 3. This should be doable with not much
> effort, as the Lucene integration in Oak is much simpler than in
> Jackrabbit Classic. It might even be possible to make oak-lucene
> version-independent, so it would work with both Lucene 3 and 4.
>
> c) Ship the jackrabbit deployment packages without Lucene integration
> for Oak. This would allow people to start playing with Oak in their
> existing deployments, but require some deployment changes for full Oak
> functionality.
>
> d) Use the class rewriting tricks in something like the Shade plugin
> [1] to be able to include both Lucene 3 *and* 4 in the same deployment
> packages. I'm not sure if this is even possible with Lucene, or how
> much effort it would require.
>
> e) Use a custom classloader setup to load the correct version of
> Lucene depending on the selected Jackrabbit mode.
>
> f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
> container, and use it to selectively deploy the required
> implementation components, including the correct version of Lucene.
>
> g) Or as a last resort, abandon the idea of a joint deployment
> package. Jackrabbit Classic and Oak would be shipped in separate
> deployment artifacts.
>
> I'm thinking of trying to implement one or two of these alternatives
> within the next few weeks, and cut Jackrabbit 2.8 based on that work
> and including something like Oak 0.16 as a beta feature. Assuming that
> approach works and Oak stabilizes as planned, we could then follow up
> with Jackrabbit 3.0 fairly soon after 2.8.
>
> [1] http://maven.apache.org/plugins/maven-shade-plugin/
>
> BR,
>
> Jukka Zitting
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Alex Parvulescu <al...@gmail.com>.
Hi,
> g) Or as a last resort, abandon the idea of a joint deployment
> package. Jackrabbit Classic and Oak would be shipped in separate
> deployment artifacts.
>
>
+1, I would also prefer this option.
alex
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Let's pick this up again!
On Thu, Jan 17, 2013 at 6:00 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
>> been created, we'd replace the current trunk with an Oak-based JCR
>> implementation.
>
> As mentioned above, instead of replacing the trunk entirely, I'd keep
> both codebases in trunk for now and include *both* the 2.x and Oak
> repositories in things like jackrabbit-webapp and
> jackrabbit-standalone, with a configuration option to decide which
> repository implementation should be used in each particular
> deployment.
I was looking at this a few months ago, and there's one big blocker
that makes such a double deployment somewhat complicated: Since
Jackrabbit 2.x ("Jackrabbit Classic"?) still uses an older version of
Lucene, it's hard merge with Oak where Lucene 4 is used. I have a few
ideas on how this problem could be resolved:
a) Upgrade Jackrabbit Classic to use Lucene 4. As discussed earlier
(http://markmail.org/message/nv5jeeoda7qe5qen) this is pretty hard,
and it's questionable whether the benefits are worth the effort.
b) Downgrade Oak to use Lucene 3. This should be doable with not much
effort, as the Lucene integration in Oak is much simpler than in
Jackrabbit Classic. It might even be possible to make oak-lucene
version-independent, so it would work with both Lucene 3 and 4.
c) Ship the jackrabbit deployment packages without Lucene integration
for Oak. This would allow people to start playing with Oak in their
existing deployments, but require some deployment changes for full Oak
functionality.
d) Use the class rewriting tricks in something like the Shade plugin
[1] to be able to include both Lucene 3 *and* 4 in the same deployment
packages. I'm not sure if this is even possible with Lucene, or how
much effort it would require.
e) Use a custom classloader setup to load the correct version of
Lucene depending on the selected Jackrabbit mode.
f) Adjust the Jackrabbit deployment packages to use an embedded OSGi
container, and use it to selectively deploy the required
implementation components, including the correct version of Lucene.
g) Or as a last resort, abandon the idea of a joint deployment
package. Jackrabbit Classic and Oak would be shipped in separate
deployment artifacts.
I'm thinking of trying to implement one or two of these alternatives
within the next few weeks, and cut Jackrabbit 2.8 based on that work
and including something like Oak 0.16 as a beta feature. Assuming that
approach works and Oak stabilizes as planned, we could then follow up
with Jackrabbit 3.0 fairly soon after 2.8.
[1] http://maven.apache.org/plugins/maven-shade-plugin/
BR,
Jukka Zitting
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Oct 23, 2012 at 5:03 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Here's an early draft of how this could work out in terms of the
> Jackrabbit roadmap:
Seems like we have fairly good consensus on the big picture, so let's
start laying some more concrete plans!
> * Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0
> version sometime around the end of this year. As usual, we'll have a
> 2.6 maintenance branch for upcoming 2.6.x patch releases.
We missed the end of the year already, but let's try to get this out
pretty soon. I'll follow up with in a separate thread.
> * Jackrabbit 2.x: Just after branching 2.6, we'd create a separate 2.x
> development branch for future work based on the current Jackrabbit
> architecture. This branch would give us a chance to more than just bug
> fixes on the 2.x codebase for at least a few more years until everyone
> is comfortable upgrading to an Oak-based repository.
In fact, after thinking about this a bit more, I'd rather keep the 2.x
codebase in trunk parallel to the new Oak components we'll be moving
in after 2.6 is branched. This should make it easier to share the code
in jcr-commons and other generic components. Having the 2.x and Oak
codebases parallel in the same trunk will also make it much easier to
implement and test good migration tools.
> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
> been created, we'd replace the current trunk with an Oak-based JCR
> implementation.
As mentioned above, instead of replacing the trunk entirely, I'd keep
both codebases in trunk for now and include *both* the 2.x and Oak
repositories in things like jackrabbit-webapp and
jackrabbit-standalone, with a configuration option to decide which
repository implementation should be used in each particular
deployment. Having both codebases included in the same deployment
packages will make it easier for downstream users to upgrade to Oak
with minimum changes to their deployments. Also things like the backup
and migration tools in jackrabbit-standalone should be easy to use
also with Oak.
With this hybrid approach I'd go first for a stable 2.8 release
sometime before summer, with the traditional 2.x repository still the
default deployment option but with Oak included as an alternative.
Then in unstable 2.9 we can deprecate the 2.x repository and make Oak
the default. Finally around the end of the year (or whenever we're
ready for it) we can cut Jackrabbit 3.0 as the stable Oak-based
repository. That release (and all 3.x versions) should still contain
also the older 2.x codebase for full backwards compatibility (except
for features deprecated already in 1.x, those we can drop in 3.0).
BR,
Jukka Zitting
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Alexander Klimetschek <ak...@adobe.com>.
+1
Cheers,
Alex
On 23.10.2012, at 16:03, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On oak-dev@ we were just discussing about the future of Oak and how
> it'll relate to Jackrabbit in general. The emerging consensus seems to
> be that we should keep Oak as a part of Jackrabbit and have Jackrabbit
> 3.0 be based on Oak.
>
> Here's an early draft of how this could work out in terms of the
> Jackrabbit roadmap:
>
> * Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0
> version sometime around the end of this year. As usual, we'll have a
> 2.6 maintenance branch for upcoming 2.6.x patch releases.
>
> * Jackrabbit 2.x: Just after branching 2.6, we'd create a separate 2.x
> development branch for future work based on the current Jackrabbit
> architecture. This branch would give us a chance to more than just bug
> fixes on the 2.x codebase for at least a few more years until everyone
> is comfortable upgrading to an Oak-based repository.
>
> * JCR 2.1 RI: The 2.x branch could also be used for developing the
> reference implementation for JSR 333 (JCR 2.1). Given current
> schedules this could become something like Jackrabbit 2.8.
>
> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
> been created, we'd replace the current trunk with an Oak-based JCR
> implementation. This "Blackrabbit" edition of Oak would come with a
> set of plugin components designed to offer as much backwards
> compatibility with existing Jackrabbit 2.x deployments as possible,
> and would ship with code that can automatically migrate or upgrade an
> existing Jackrabbit 2.x repository. The target date for Jackrabbit 3.0
> would be sometime next year, with focus on stability and backwards
> compatibility.
>
> * Jackrabbit 3.x: After Jackrabbit 3.0 is out we can continue working
> on things like performance and scalability, integrations with
> different backends and clients, and new features for future Jackrabbit
> 3.x releases. And since Jackrabbit 3.0 will be based on a fresh new
> underlying architecture from Oak, it's likely that we'll encounter a
> number of smaller issues to be fixed or improved.
>
> WDYT?
>
> [1] http://markmail.org/message/ga4mn2x2xqsvzwg6
>
> BR,
>
> Jukka Zitting
Re: Roadmap for Jackrabbit 2.x and 3.0
Posted by Michael Dürig <md...@apache.org>.
Sounds like a plan ;-) +1
Michael
On 23.10.12 15:03, Jukka Zitting wrote:
> Hi,
>
> On oak-dev@ we were just discussing about the future of Oak and how
> it'll relate to Jackrabbit in general. The emerging consensus seems to
> be that we should keep Oak as a part of Jackrabbit and have Jackrabbit
> 3.0 be based on Oak.
>
> Here's an early draft of how this could work out in terms of the
> Jackrabbit roadmap:
>
> * Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0
> version sometime around the end of this year. As usual, we'll have a
> 2.6 maintenance branch for upcoming 2.6.x patch releases.
>
> * Jackrabbit 2.x: Just after branching 2.6, we'd create a separate 2.x
> development branch for future work based on the current Jackrabbit
> architecture. This branch would give us a chance to more than just bug
> fixes on the 2.x codebase for at least a few more years until everyone
> is comfortable upgrading to an Oak-based repository.
>
> * JCR 2.1 RI: The 2.x branch could also be used for developing the
> reference implementation for JSR 333 (JCR 2.1). Given current
> schedules this could become something like Jackrabbit 2.8.
>
> * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have
> been created, we'd replace the current trunk with an Oak-based JCR
> implementation. This "Blackrabbit" edition of Oak would come with a
> set of plugin components designed to offer as much backwards
> compatibility with existing Jackrabbit 2.x deployments as possible,
> and would ship with code that can automatically migrate or upgrade an
> existing Jackrabbit 2.x repository. The target date for Jackrabbit 3.0
> would be sometime next year, with focus on stability and backwards
> compatibility.
>
> * Jackrabbit 3.x: After Jackrabbit 3.0 is out we can continue working
> on things like performance and scalability, integrations with
> different backends and clients, and new features for future Jackrabbit
> 3.x releases. And since Jackrabbit 3.0 will be based on a fresh new
> underlying architecture from Oak, it's likely that we'll encounter a
> number of smaller issues to be fixed or improved.
>
> WDYT?
>
> [1] http://markmail.org/message/ga4mn2x2xqsvzwg6
>
> BR,
>
> Jukka Zitting
>
AW: Roadmap for Jackrabbit 2.x and 3.0
Posted by KÖLL Claus <C....@TIROL.GV.AT>.
sounds good to me ..
+1
greets
claus