Continuum: where to now

[Brett Porter <br...@apache.org>]

Hi,

Ok, here's a summary of what I did with the continuum model:
- rebuilt the model from scratch based on the web design.
- implemented it separately and tested it thoroughly in isolation.
- migrated the app over to the new model, removing the old one

Changes in the new model:
- package is o.a.m.c.model.* (added model. to the package), removed
Continuum from the class names. This is consistent with m2's use of the
model.
- many-to-many relationship was broken down into 1-to-many. This was
necessitated by the design, not any technological limitation.
- added dependant relationships for most
- changed identifiers to integers rather than string ints, and removed
id fields from those not meant to be looked up on their own
- constructed fetch groups based on the page flows
- other small things, eg "forced" changed to "trigger" so we can track
what caused the build (web, soap req, schedule, etc)

Things still broken:
- I haven't gone back and updated velocity templates. Doing that now.
- There may be some more bugs in the web stuff that wasn't covered by
the integration tests. I'm checking it over.
- I haven't done the persistence/testing for the users/permissions stuff yet

There are  afew areas I'm still not happy with. The fetch groups don't
seem to fit well with what is required a lot of the time. I'm wondering
whether we are better off making everything be in the default fetch
group, and lazy loading the lists instead. It seems since we are only
doing this as an optimization that'd be a better way to do it.

We'd still need to avoid long lists, ie build results. I think that
should not be a field on the project, and instead it should just have
references to the last successful build, last finished build, current
build (either in progress or finished).

I'm not particularly happy with using store methods "mid-way" through a
block of code. I'm not sure if it does any dirty checking when you do a
re-attach,but I see potential to read something, have it changed
externally, then write over the top of it. The fact that we are
re-retrieving from the db at random points could make this harder to
track. I think we should be in the practise of getting all we need from
the db at the start, modifying the detached objects, then updating them
with dirty check at the end. We need to be able to resolve common cases
where we can recover, and fail gracefully when it can't. At the end of
the day, this isn't preventing it working now, so I'll just schedule a
review of the use of the store later as it may be a source of ongoing
bugs otherwise.

So, where do we go from here?

I would like to see us knock off all the pages in the design as soon as
possible. This should be the easy bit as it is all just forms and
presentation now I believe. Some of the features aren't supported in the
backend yet (like security, displaying test reports, generated
artifacts), so they can be omitted for now. Does everyone agree?

Cheers,
Brett

Re: Continuum: where to now

[David Le Strat <dl...@yahoo.com>]

Brett,

I have checked out Continuum code and it looks great. 
Good luck for your 1.0 release.  I look forward to it.

A few thoughts for future direction:  it would be
quite easy to convert the continuum site it to a
portlet.  It is all velocity based and a portal engine
like Jetspeed 2 fully supports velocity. 
Additionally, you may be interested in checking out
Jetspeed 2 security module which provides both
management APIs and JAAS authorization and
authentication.  The security component is a spring
based so that may save you some work there if you
planned to integrate security with your application
(see
http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/index.html)

Regards,

David Le Strat.

--- Brett Porter <br...@apache.org> wrote:

> Thanks for the offer David. We've got a bit of an
> investment in the
> current framework, but we are actively discussing
> options, and are
> definitely interested in looking into making it work
> more ike a portal.
> 
> I think we'd defer until after Continuum 1.0 to make
> this sort of change
> if at all, but we'll certainly discuss it here.
> 
> Cheers,
> Brett
> 
> David Le Strat wrote:
> 
> >Brett,
> >
> >Just curious.  Have you considered leveraging a
> >portal/portlet framework at all for Continuum's web
> >site?  It seems to me that a lot of things around
> >security, report entitlement, plus customizability
> >would be provided out of the box.  If you guys are
> >interested, check out the portals project.  There
> may
> >even be people willing to help out including
> myself.
> >
> >Regards,
> >
> >David Le Strat.
> >
> >  
> >
> 
> 


________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: Continuum: where to now

[Brett Porter <br...@apache.org>]

Thanks for the offer David. We've got a bit of an investment in the
current framework, but we are actively discussing options, and are
definitely interested in looking into making it work more ike a portal.

I think we'd defer until after Continuum 1.0 to make this sort of change
if at all, but we'll certainly discuss it here.

Cheers,
Brett

David Le Strat wrote:

>Brett,
>
>Just curious.  Have you considered leveraging a
>portal/portlet framework at all for Continuum's web
>site?  It seems to me that a lot of things around
>security, report entitlement, plus customizability
>would be provided out of the box.  If you guys are
>interested, check out the portals project.  There may
>even be people willing to help out including myself.
>
>Regards,
>
>David Le Strat.
>
>  
>

Re: Continuum: where to now

[David Le Strat <dl...@yahoo.com>]

Brett,

Just curious.  Have you considered leveraging a
portal/portlet framework at all for Continuum's web
site?  It seems to me that a lot of things around
security, report entitlement, plus customizability
would be provided out of the box.  If you guys are
interested, check out the portals project.  There may
even be people willing to help out including myself.

Regards,

David Le Strat.

--- Brett Porter <br...@apache.org> wrote:

> Hi,
> 
> Ok, here's a summary of what I did with the
> continuum model:
> - rebuilt the model from scratch based on the web
> design.
> - implemented it separately and tested it thoroughly
> in isolation.
> - migrated the app over to the new model, removing
> the old one
> 
> Changes in the new model:
> - package is o.a.m.c.model.* (added model. to the
> package), removed
> Continuum from the class names. This is consistent
> with m2's use of the
> model.
> - many-to-many relationship was broken down into
> 1-to-many. This was
> necessitated by the design, not any technological
> limitation.
> - added dependant relationships for most
> - changed identifiers to integers rather than string
> ints, and removed
> id fields from those not meant to be looked up on
> their own
> - constructed fetch groups based on the page flows
> - other small things, eg "forced" changed to
> "trigger" so we can track
> what caused the build (web, soap req, schedule, etc)
> 
> Things still broken:
> - I haven't gone back and updated velocity
> templates. Doing that now.
> - There may be some more bugs in the web stuff that
> wasn't covered by
> the integration tests. I'm checking it over.
> - I haven't done the persistence/testing for the
> users/permissions stuff yet
> 
> There are  afew areas I'm still not happy with. The
> fetch groups don't
> seem to fit well with what is required a lot of the
> time. I'm wondering
> whether we are better off making everything be in
> the default fetch
> group, and lazy loading the lists instead. It seems
> since we are only
> doing this as an optimization that'd be a better way
> to do it.
> 
> We'd still need to avoid long lists, ie build
> results. I think that
> should not be a field on the project, and instead it
> should just have
> references to the last successful build, last
> finished build, current
> build (either in progress or finished).
> 
> I'm not particularly happy with using store methods
> "mid-way" through a
> block of code. I'm not sure if it does any dirty
> checking when you do a
> re-attach,but I see potential to read something,
> have it changed
> externally, then write over the top of it. The fact
> that we are
> re-retrieving from the db at random points could
> make this harder to
> track. I think we should be in the practise of
> getting all we need from
> the db at the start, modifying the detached objects,
> then updating them
> with dirty check at the end. We need to be able to
> resolve common cases
> where we can recover, and fail gracefully when it
> can't. At the end of
> the day, this isn't preventing it working now, so
> I'll just schedule a
> review of the use of the store later as it may be a
> source of ongoing
> bugs otherwise.
> 
> So, where do we go from here?
> 
> I would like to see us knock off all the pages in
> the design as soon as
> possible. This should be the easy bit as it is all
> just forms and
> presentation now I believe. Some of the features
> aren't supported in the
> backend yet (like security, displaying test reports,
> generated
> artifacts), so they can be omitted for now. Does
> everyone agree?
> 
> Cheers,
> Brett
> 
> 
> 


________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com