jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Improving the accessibility of the Jackrabbit core
Date Wed, 06 Sep 2006 10:10:13 GMT
On 9/6/06, Nicolas <ntoper@gmail.com> wrote:
> 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.
> >
> Hi,
> 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 don't follow your argumentation. why would this lead to 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).
> BR
> Nicolas
> my blog! http://www.deviant-abstraction.net !!

View raw message