continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <>
Subject Re: Improvements (general and performances) : next steps
Date Mon, 30 Jun 2008 14:20:14 GMT
On Mon, Jun 30, 2008 at 4:02 PM, Brett Porter <> wrote:

> On 30/06/2008, at 11:42 PM, Emmanuel Venisse wrote:
>  Hi,
>> In next days, I'll work on some improvements.
>> Notification:
>> I started to refactor the notification part. I'm removing
>> plexus-notification and simplify APIs. In this refactoring, I remove the
>> context HashMap and use a "real" object (MessageContext) so it is more
>> easy
>> to know what can be used from the context. This refactoring is a first
>> step
>> for the notification part because I want in the future to allow a user to
>> develop a new notifier without to modify some Continuum code or existing
>> JSPs, a notifier will be a plugin but not in 1.2
>> I'll remove plexus-mail-sender too and will replace it by the Spring mail
>> component
>> I'll change the library used by the MSN notifier.
> Seems to make sense to me.

spring mail and msn lib changes won't be in the global notification change.
We don't need a branch for notification changes.

>> Performance:
>> During a build, we won't do DB access, it is a performance issue actually.
>> All will be done in memory and the result will be stored at the end.
>> I want to remove all HashMap context used actually in the build controller
>> and build actions,  they aren't developer friendly.
>> To reduce DB access and improve performance a lot, I'd like to use ehcache
>> for all major objects (all objects without build results and associated)
> Certainly what I want to see, but sounds like a big, scary, destabilising
> change :)
> Can we continue with this step by step, or on a feature branch or for 1.3
> or something like that?

Sure, I won't work on it on trunk :) it will be first on a branch.
I don't know yet if all will be in 1.2 or not but it will be done step by
step, I don't want to break all ;)


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