On 9/6/06, David Nuescheler <[EMAIL PROTECTED]> 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 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 !!
