jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: Improving the accessibility of the Jackrabbit core
Date Wed, 06 Sep 2006 09:12:34 GMT
On 9/6/06, David Nuescheler <david.nuescheler@gmail.com> wrote:

> While I agree that we need to have a modular design where people can
> plug-in their extensions at certain defined interfaces and extension
> points,
> I would discourage the idea that every user needs to be able to submit
> patches to the core.
> In my mind the core should be very compact and very controlled since
> it has to be extremely stable and scalable, meaning that there is not
> really a need to have dozens of developers working on a more
> "smallish" core.


My two cents on the subject drawing from my experience on the backup tool.

At first Jukka and I wanted to avoid impact on the core for the reasons you
mentionned. It turned out we had to eventually update some parts of the
core: some functionnalities were simply not there. We minimized the changes
(only a few lines)... But they were quite bad (I exposed something that
shouldn't). After some rethinking and a few try out, I am back to my initial
plan with a few classes added to the core.

This example shows the Core is "not over" in the sense, it lacks some
functionnality (for instance in my case a way to import the versions). I
think we need to remember JR is still a fairly new project and some use
cases have still not been detected.

Some functionnalities have not been needed yet for the core contributors but
might emerge from other companies/individual (for instance my company would
need to extend JR to support our needs). I think discouraging those
contributions can be a bad idea: we should encourage them, keep the code and
refactor them if necessary. This way both the contributor and the communitu
take benefit from it: a new functionnality with a cleaner code.

I agree with you though that we should encourage contribution and not update
to the core. But we should document the core. In my case, it took me a lot
of time the part I needed (I wrote a new UpdatableStateManager since I
couldn't figure out how the EventFactory was working).

my blog! http://www.deviant-abstraction.net !!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message