continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <emmanuel.veni...@gmail.com>
Subject Re: Improvements (general and performances) : next steps
Date Mon, 30 Jun 2008 15:18:09 GMT
On Mon, Jun 30, 2008 at 5:14 PM, Olivier Lamy <olamy@apache.org> wrote:

> 2008/6/30 Emmanuel Venisse <emmanuel.venisse@gmail.com>:
> > 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
>
> BuildContext with some methods like getProjectId ?


no, but getProject. If we use getProjectId, we'll need to get the project
from the DB ;)

>
>
> > 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
>
> Cool  (olamy like the plugin idea ;-) )
>
> > 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.
> >
> > 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)
>
> Sure (not ok getProjectId but getProject :-) )
>
> >
> > What do you think?
>
> Sounds great !
>
>
> > Emmanuel
> >
>
> Thanks,
> --
> Olivier
>

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