well, I am working on finishing up some lingering project group functionality now, but once I knock it off my list I'll work on the testing some. I'll need to get up to speed on the latest integration testing work you have been working on jason, and emm mentioned on irc a while back that he was going to take a stab at bringing the web testing back on line so I'll ping him and work with him on that...
also, its looks like there is a bit of a split on where to go release wise atm, but I think we can all generally acknowledge that the tests need to get improved, at the very least getting the web testing back where it was before the ui refactor to webwork. Perhaps we should shoot for a feature freeze of sorts for the middle of november and check where we are for a 1.1 release around that time. A month should be more then enough time to get the test case positions recovered to an acceptable lvl and get a mess of the outstanding issues resolved/lacking features fixed up. jesse On 10/17/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: > I agree with Emmanuel. IIRC, the profiles are already in the model, > and basic choice of which JDK and maven/ant installation to use > should be straightforward and extremely useful. I agree that making > it more pervasive and using the toolchain support would be even > better, but I don't believe it needs to wait for that. > I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. > - Brett > > On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: > >> The introduction of continuum profiles isn't impacted by the >> DefaultContinuum refactoring. >> If we don't provide a full continuum profiles implementation in >> 1.1, I think we can do a minimal one with only the possibility to >> choose the maven1/maven2/ant/java home directories and use them >> instead of using maven/ant/mvn/java from the PATH. This feature >> isn't big to do. >> >> In 1.1, I'd like to see the possibility to choose in build >> definitions if a project is built with an update (like it's done >> actually) or with a clean checkout. >> >> The last point, I'd like to see in 1.1 is the dependency/parent >> change build-trigger. >> >> All these features are awaited by users since a long time. I don't >> think the implementation will take lot of time, so they can be add >> in 1.1. >> >> Of course, we need a database migration tool for the release too. >> >> Emmanuel >> >> Jesse McConnell a écrit : >>> I was going to try and wrap my head about what needed to get wrapped >>> up for a 1.1 release of continuum this week when I got to talking to >>> emmanuel this morning. >>> I had been under the impression that we were getting near a point >>> that >>> we might want to polish things up and cut a 1.1 release but emm was >>> thinking that we ought to have another big push for new features >>> before we start polishing things up. So I told him I would mention >>> our talk and see what kinda interest we got from people on new >>> features and who might want to tackle what in the short term, or >>> if we >>> wanted to put some things out into the longer term bin. >>> One of the major things that I had been thinking we would push >>> off to >>> the 1.2 release was the profiles. Its a slightly overridden term as >>> it has little to do with maven profiles, but in my mind at least the >>> profiles were going to be 1/3 of a trinity by which builds could be >>> setup to run. >>> The trinity being: profile (maven instance, env vars, maven >>> profiles, >>> jdk instance, etc), temporal ( scheduled cron, when dependency >>> changes, scm activity, etc) and the project group (bundle of >>> projects). I was figuring that those three things taken together >>> ought meet the requirements for building what, where and when. It >>> would be a matter of setting up the permutations of those three >>> components, for example: 2 profiles, 1 schedule, 1 project group >>> would >>> make 2 instances of schedulable FOO. >>> Anyway, I digress...profiles would be one large feature that >>> would be >>> wonderful to have in continuum, sooner the better. But it would be >>> pretty massive effects on the codebase. So massive that I would >>> think >>> we ought to consider splitting up the DefaultContinuum object >>> into the >>> workflows that have been kicked around, making things like 'Add >>> Project To Project Group' extensible by users so they can trigger >>> any >>> other processes they might want running on those events. Trygve has >>> some definite ideas in this area, perhaps using the plexus-spe code. >>> The actions in continuum have been a first pass attempt at >>> starting to >>> break things out of the DC object which is pretty big atm. >>> If we were going to rip the top off of the DefaultContinuum >>> object and >>> add/modify in the profile concepts into the store then we really >>> ought >>> to clean up the whole store api which is more painful to work with >>> then it really should be. joakim and I had a lot of success with >>> structuring things nicely in the plexus-security jdo stores and we >>> could probably apply a ton of the concepts there in terms of api to >>> the continuum-store and make it scads easier to work with. >>> and on and on. >>> I agree with Emmanuel that since 1.1 as it currently stands is not >>> backwards compatible (I think) with the old database we ought to >>> just >>> add in what we need now...But doing this will definitely move out a >>> 1.1 release into the new year...and is that something we want to do? >>> I dunno really, personally I would be cool with adding in >>> profiles and >>> refactoring the core chunks of continuum up now and get it over >>> with, >>> but does anyone else have anything to say on the matter? I know we >>> have had a lot more interest recently by folks like rahul and >>> christian on participating, would you guys be interested in >>> taking on >>> some of these challenges with us? Theres nothing like ripping >>> through >>> the guts of code to really get involved :) >>> thoughts? should we open this out to the users list maybe? >>> jesse >
-- jesse mcconnell [EMAIL PROTECTED]
