Just to jump in. I don't really see the limitation with the current
ContinuumStore object. In fact, I would say the only real issue I
see around it is that too many components are dependent upon it which
makes Continuum somewhat database-centric. In most cases these
components are just u
On Wed, 2005-12-14 at 14:58 -0800, Carlos Sanchez wrote:
> On 12/14/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
> > I still disagree with splitting up the ContinuumStore into a set of
> > DAOs. I've never seen the advantage of having a single DAO for each
> > domain object.
>
> They will be reu
On 12/14/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
> I still disagree with splitting up the ContinuumStore into a set of
> DAOs. I've never seen the advantage of having a single DAO for each
> domain object.
They will be reusable in other applicaitons. If we're thinking about
creting other ap
On Wed, 2005-12-14 at 19:30 +0100, Emmanuel Venisse wrote:
> ok, so we'll have some data object store access (ProjectStore, BuildStore...)
> and DefaultContinuum
> will use them. Webwork actions will use them too or they'll use Continuum
> interface?
I still disagree with splitting up the Conti
I think we have to be careful when splitting up a public api like this.
It's possible Continuum may need to be embedded someday, and if so, it
would be much better to have a single interface for controlling
it...even if it means that interface delegates most of its work. While I
think you can p
On Tue, 2005-12-13 at 16:10 +0100, Emmanuel Venisse wrote:
> Hi,
>
> I'd like to know your opinions about the continuum refactoring for 1.1
>
> What we'll do?
>
> Replace plexus-summit/velocity by JSP/WebWork/SiteMesh
>
> What i'd like to do?
>
> Actually, DefaultContinuum class is our central
