[jr3] Jackrabbit 3 in trunk

[Jukka Zitting <ju...@gmail.com>]

Hi,

Thomas has done some nice work with the jackrabbit-j3 prototype in the
sandbox. To make this codebase easily available to other developers
and to allow better reuse of existing Jackrabbit code and integration
with things like jackrabbit-standalone, I propose that we move the
component from the sandbox to Jackrabbit trunk. This means that the
component would be included as a technology preview in future 2.x
releases and that we'd include it in our normal continuous integration
builds. The downside is the increased build time in trunk.

WDYT?

BR,

Jukka Zitting

Re: [jr3] Jackrabbit 3 in trunk

[Alexander Klimetschek <ak...@day.com>]

On Fri, May 14, 2010 at 08:25, Angela Schreiber <an...@day.com> wrote:
> not sure... i have the impression that it is too early to move
> the prototype out of the sandbox.
>
> and i don't fully understand your arguments for the move: reuse
> of existing code is achieved by adding dependencies to other
> modules in either way, isn't it? and furthermore, i don't understand
> why a sandbox project wasn't easily available... my criteria for a
> move into trunk would rather be: this prototype isn't a prototype any
> more and we feel comfortable to include it into your regular release
> cycle.

I agree. Putting it in the trunk and including it in upcoming 2.x
releases will be rather confusing for users at the moment. We should
only put this in the normal release cycle when we can be confident
that it works more or less stable. I fear that when people hear about
the improvements it should finally bring, they will try it out and
will be disappointed if it's not finished yet.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [jr3] Jackrabbit 3 in trunk

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, May 14, 2010 at 8:25 AM, Angela Schreiber <an...@day.com> wrote:
> and i don't fully understand your arguments for the move: reuse
> of existing code is achieved by adding dependencies to other
> modules in either way, isn't it?

I believe there will be many cases where some refactoring of existing
jackrabbit-core classes is needed for them to be easily reusable in
jackrabbit-j3. It'll be easier to handle such refactorings when both
codebases are within the same svn root. Currently Thomas has just been
copying relevant parts of jackrabbit-core code.

> and furthermore, i don't understand why a sandbox project wasn't
> easily available...

I'm hoping to eliminate the extra steps of the separate svn checkout,
maven build and IDE setup. For example, how many of us have even
checked out and built the jackrabbit-j3 component so far? (Hint, the
default maven build hasn't worked for the last three weeks.)

> my criteria for a move into trunk would rather be: this prototype isn't
> a prototype any more and we feel comfortable to include it into your
> regular release cycle.

Good point. Thomas, what's your feeling about the codebase?

BR,

Jukka Zitting

Re: [jr3] Jackrabbit 3 in trunk

[Felix Meschberger <fm...@gmail.com>]

Hi,

Hmm, on second thought -- maybe moving to trunk is fine, but in a
separate clearly separate area and not included in any upcoming release.

This is work in progress and interested parties -- hopefully also people
providing code -- are developers not end users.

Regards
Felix


On 14.05.2010 18:43, Felix Meschberger wrote:
> Hi
> 
> As much as I understand that we should push JR 3 forward, I agree with
> Angela's position.
> 
> I don't think that adding JR3 as a techno preview in upcoming JR 2 will
> do any good -- except making the release process and understanding the
> code even more complex.
> 
> Regards
> Felix
> 
> On 14.05.2010 08:25, Angela Schreiber wrote:
>> hi jukka
>>
>>> Thomas has done some nice work with the jackrabbit-j3 prototype in the
>>> sandbox. To make this codebase easily available to other developers
>>> and to allow better reuse of existing Jackrabbit code and integration
>>> with things like jackrabbit-standalone, I propose that we move the
>>> component from the sandbox to Jackrabbit trunk. This means that the
>>> component would be included as a technology preview in future 2.x
>>> releases and that we'd include it in our normal continuous integration
>>> builds. The downside is the increased build time in trunk.
>>
>> not sure... i have the impression that it is too early to move
>> the prototype out of the sandbox.
>>
>> and i don't fully understand your arguments for the move: reuse
>> of existing code is achieved by adding dependencies to other
>> modules in either way, isn't it? and furthermore, i don't understand
>> why a sandbox project wasn't easily available... my criteria for a
>> move into trunk would rather be: this prototype isn't a prototype any
>> more and we feel comfortable to include it into your regular release
>> cycle.
>>
>> regards
>> angela
>>
>>> WDYT?
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>>

Re: [jr3] Jackrabbit 3 in trunk

[Felix Meschberger <fm...@gmail.com>]

Hi

As much as I understand that we should push JR 3 forward, I agree with
Angela's position.

I don't think that adding JR3 as a techno preview in upcoming JR 2 will
do any good -- except making the release process and understanding the
code even more complex.

Regards
Felix

On 14.05.2010 08:25, Angela Schreiber wrote:
> hi jukka
> 
>> Thomas has done some nice work with the jackrabbit-j3 prototype in the
>> sandbox. To make this codebase easily available to other developers
>> and to allow better reuse of existing Jackrabbit code and integration
>> with things like jackrabbit-standalone, I propose that we move the
>> component from the sandbox to Jackrabbit trunk. This means that the
>> component would be included as a technology preview in future 2.x
>> releases and that we'd include it in our normal continuous integration
>> builds. The downside is the increased build time in trunk.
> 
> not sure... i have the impression that it is too early to move
> the prototype out of the sandbox.
> 
> and i don't fully understand your arguments for the move: reuse
> of existing code is achieved by adding dependencies to other
> modules in either way, isn't it? and furthermore, i don't understand
> why a sandbox project wasn't easily available... my criteria for a
> move into trunk would rather be: this prototype isn't a prototype any
> more and we feel comfortable to include it into your regular release
> cycle.
> 
> regards
> angela
> 
>> WDYT?
>>
>> BR,
>>
>> Jukka Zitting
>>
> 
> 

Re: [jr3] Jackrabbit 3 in trunk

[Thomas Müller <th...@day.com>]

Hi,

> objectives of the
> jr3 project is to deliver better performance than jr2 on scalability,
> concurrency, latency, etc., it would be helpful to have an automated stress
> test framework

That's true. There are already a few such test cases, but more are
required. Patches are welcome of course :-)

However I fear most people will ignore this prototype unless it is
actually usable. That's why I think adding features is important as
well. This doesn't mean the prototype needs to pass the TCK, but at
least the basic operations should work as expected.

> It's easier to fix deep architectural issues before a bunch of code has been
> written around the architecture, so the priority should be to have code that
> breaks the architecture (highlighting the weak points) before having code
> that uses the architecture (highlighting the strong points).

In other words, the architecture needs to be correct before adding
features. That's true. Probably "clustering" should be added before
"versioning", because clustering has a higher impact on the
architecture.

Regards,
Thomas

Re: [jr3] Jackrabbit 3 in trunk

[Michael D Robinson <md...@thoughtworks.com>]

Hi, Thomas,

What I mean is that, if I understand correctly, one of the objectives of the
jr3 project is to deliver better performance than jr2 on scalability,
concurrency, latency, etc., it would be helpful to have an automated stress
test framework to demonstrate progress against these objectives earlier in
the project, rather than later.

It's easier to fix deep architectural issues before a bunch of code has been
written around the architecture, so the priority should be to have code that
breaks the architecture (highlighting the weak points) before having code
that uses the architecture (highlighting the strong points).

Once performance levels have been established that everyone is happy with,
the automated stress test framework then provides a check against
regressions from these levels as the full and richer feature set is built
out.

          -Michael Robinson

On Wed, May 19, 2010 at 11:39 PM, Thomas Müller <th...@day.com>wrote:

> Hi,
>
> > My suggestion (admittedly as a bystander) would be that the sooner people
> > can start breaking it, the sooner it can get fixed, so prioritize
> activities
> > based on first getting it to the point of breakability (rather than
> > usability), and then merge.
>
> Sorry, I don't understand what you mean exactly... Could you give an
> example?
>
> Regards,
> Thomas
>

Re: [jr3] Jackrabbit 3 in trunk

[Thomas Müller <th...@day.com>]

Hi,

> My suggestion (admittedly as a bystander) would be that the sooner people
> can start breaking it, the sooner it can get fixed, so prioritize activities
> based on first getting it to the point of breakability (rather than
> usability), and then merge.

Sorry, I don't understand what you mean exactly... Could you give an example?

Regards,
Thomas

Re: [jr3] Jackrabbit 3 in trunk

[Michael D Robinson <md...@thoughtworks.com>]

On Fri, May 14, 2010 at 10:48 PM, Thomas Müller <th...@day.com>wrote:

> Hi,
>
> So far the prototype is not yet "usable", meaning too many features
> are missing, tools are missing, documentation is missing.


Ahem.


> I guess this
> needs to be fixed first, so that it becomes somewhat usable (even with
> limited functionality).
>

My suggestion (admittedly as a bystander) would be that the sooner people
can start breaking it, the sooner it can get fixed, so prioritize activities
based on first getting it to the point of breakability (rather than
usability), and then merge.

       -Michael Robinson

Re: [jr3] Jackrabbit 3 in trunk

[Thomas Müller <th...@day.com>]

Hi,

So far the prototype is not yet "usable", meaning too many features
are missing, tools are missing, documentation is missing. I guess this
needs to be fixed first, so that it becomes somewhat usable (even with
limited functionality). We also need to find out how / where exactly
we want to add it in the trunk.

Regards,
Thomas

Re: [jr3] Jackrabbit 3 in trunk

[Angela Schreiber <an...@day.com>]

hi jukka

> Thomas has done some nice work with the jackrabbit-j3 prototype in the
> sandbox. To make this codebase easily available to other developers
> and to allow better reuse of existing Jackrabbit code and integration
> with things like jackrabbit-standalone, I propose that we move the
> component from the sandbox to Jackrabbit trunk. This means that the
> component would be included as a technology preview in future 2.x
> releases and that we'd include it in our normal continuous integration
> builds. The downside is the increased build time in trunk.

not sure... i have the impression that it is too early to move
the prototype out of the sandbox.

and i don't fully understand your arguments for the move: reuse
of existing code is achieved by adding dependencies to other
modules in either way, isn't it? and furthermore, i don't understand
why a sandbox project wasn't easily available... my criteria for a
move into trunk would rather be: this prototype isn't a prototype any
more and we feel comfortable to include it into your regular release
cycle.

regards
angela

> WDYT?
> 
> BR,
> 
> Jukka Zitting
>