continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: contents of a 1.1 release
Date Wed, 18 Oct 2006 00:11:31 GMT
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.


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** + bus 905.640.1119 + mob 416.998.6023*

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message