[continuum build - FAILED - update] Wed Aug 17 08:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.08.txt
[continuum build - FAILED - update] Wed Aug 17 08:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.083000.txt
[continuum build - FAILED - update] Wed Aug 17 11:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.11.txt
[continuum build - FAILED - update] Wed Aug 17 12:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.12.txt
[continuum build - FAILED - update] Wed Aug 17 14:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.14.txt
[continuum build - FAILED - update] Wed Aug 17 14:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.143000.txt
[continuum build - FAILED - update] Wed Aug 17 15:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.153000.txt
[continuum build - FAILED - update] Wed Aug 17 16:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.16.txt
[continuum build - FAILED - update] Wed Aug 17 16:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.163000.txt
[continuum build - FAILED - update] Wed Aug 17 17:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.173000.txt
[continuum build - FAILED - update] Wed Aug 17 17:39:45 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.173945.txt
[continuum build - FAILED - update] Wed Aug 17 18:04:57 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.180457.txt
[continuum build - FAILED - update] Wed Aug 17 18:06:17 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.180617.txt
[continuum build - FAILED - update] Wed Aug 17 18:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.183000.txt
[continuum build - FAILED - update] Wed Aug 17 18:31:13 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.183114.txt
[continuum build - SUCCESS - update] Wed Aug 17 18:34:21 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050817.183421.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050817.183421.txt
[continuum build - FAILED - update] Thu Aug 18 01:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050818.01.txt
[continuum build - SUCCESS - update] Thu Aug 18 01:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050818.013000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050818.013000.txt
Re: Continuum: where to now
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 [EMAIL PROTECTED] 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
Re: Continuum: where to now
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.
[jira] Updated: (CONTINUUM-243) Ability to mass edit projects or define default goal
[ http://jira.codehaus.org/browse/CONTINUUM-243?page=all ] Brett Porter updated CONTINUUM-243: --- Fix Version: 1.0-beta-1 Ability to mass edit projects or define default goal Key: CONTINUUM-243 URL: http://jira.codehaus.org/browse/CONTINUUM-243 Project: Continuum Type: New Feature Components: continuum-web Versions: 1.0-alpha-3 Reporter: Yann Le Du Priority: Minor Fix For: 1.0-beta-1 At the moment, the default goal for a new project is clean:clean install. Say we want to make it clean:clean install site:site site:deploy for one project -- OK. But say for 10 or more projects... The idea would be to : * either to mass edit project goals * either to define a custom default goal for new projects Hope it is clear enough... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-265) Concurrent builds
[ http://jira.codehaus.org/browse/CONTINUUM-265?page=all ] Brett Porter updated CONTINUUM-265: --- Fix Version: 1.0-beta-1 Concurrent builds - Key: CONTINUUM-265 URL: http://jira.codehaus.org/browse/CONTINUUM-265 Project: Continuum Type: New Feature Components: continuum-core Reporter: Torsten Curdt Fix For: 1.0-beta-1 Instead of processing the builds sequentially it would be great to be able to specify how many projects are being build concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-143) We need to categorize error states and display them useful messages to the user
[ http://jira.codehaus.org/browse/CONTINUUM-143?page=all ] Brett Porter updated CONTINUUM-143: --- Fix Version: (was: 1.0-alpha-4) 1.0-beta-1 We need to categorize error states and display them useful messages to the user --- Key: CONTINUUM-143 URL: http://jira.codehaus.org/browse/CONTINUUM-143 Project: Continuum Type: Improvement Versions: 1.0-alpha-3 Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 1.0-beta-1 Right now we're only tracking checkout errors but we need to categorize all error so that we can easily extract them and display useful messages to the user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-46) view the build schedule
[ http://jira.codehaus.org/browse/CONTINUUM-46?page=all ] Brett Porter updated CONTINUUM-46: -- Fix Version: (was: 1.0-alpha-4) 1.0-beta-1 view the build schedule --- Key: CONTINUUM-46 URL: http://jira.codehaus.org/browse/CONTINUUM-46 Project: Continuum Type: New Feature Reporter: Brett Porter Assignee: Jason van Zyl Priority: Minor Fix For: 1.0-beta-1 it would be good to be able to display an overall view of the build schedule so you can see what builds are coming up, or just done. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-254) Increase the length of the input fields in the web interface
[ http://jira.codehaus.org/browse/CONTINUUM-254?page=all ] Brett Porter updated CONTINUUM-254: --- Fix Version: (was: 1.0-alpha-4) 1.0-beta-1 Increase the length of the input fields in the web interface Key: CONTINUUM-254 URL: http://jira.codehaus.org/browse/CONTINUUM-254 Project: Continuum Type: Improvement Reporter: Jason van Zyl Fix For: 1.0-beta-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-137) Store dependency information at the ContinuumProject level
[ http://jira.codehaus.org/browse/CONTINUUM-137?page=all ] Brett Porter updated CONTINUUM-137: --- Fix Version: (was: 1.0-alpha-4) 1.0-beta-1 Environment: we are storing this, but I think we might need to get more info from the projects in the group to mark this complete yet Store dependency information at the ContinuumProject level -- Key: CONTINUUM-137 URL: http://jira.codehaus.org/browse/CONTINUUM-137 Project: Continuum Type: New Feature Versions: 1.0-alpha-3 Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 1.0-beta-1 In order to be able to build in any deterministic order we need dependency information on all the projects entered into the system. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-68) Make Continuum control database initialization and destruction.
[ http://jira.codehaus.org/browse/CONTINUUM-68?page=all ] Brett Porter updated CONTINUUM-68: -- Fix Version: (was: 1.0-alpha-4) 1.0-beta-1 Environment: we do this, but we could do it better Make Continuum control database initialization and destruction. --- Key: CONTINUUM-68 URL: http://jira.codehaus.org/browse/CONTINUUM-68 Project: Continuum Type: Improvement Components: continuum-core Versions: 1.0-alpha-1 Reporter: Trygve Laugstol Assignee: Trygve Laugstol Fix For: 1.0-beta-1 Continuum should be able to autodetect if the application has been properly configured and if not autmatically set up a database given a configuration either from the user or from a configuration file. This should possibly be integrated into the web view so the application won't start up all the way without a proper storage. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
