Actually, To Emannuel's point about building with clean checkout or update, I'm working on such a thing, and should have a patch this weekend. It'll also include the per-group/per-project/per-build-def working directories, per my conversation with Kenney, and the "do you force a build on change, or always build" key.
Note: some of these options are mutually exclusive, but they're all related. Christian. 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. > > - 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 > -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
