continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: contents of a 1.1 release
Date Thu, 19 Oct 2006 23:39:09 GMT
Something I saw a while back and have been reminded of (they just had  
a recent release):

Worth looking at too? It builds on top of jWebUnit and others, and  
might make authoring test cases easier.

And they build with Maven :)

- Brett

On 19/10/2006, at 1:40 AM, Emmanuel Venisse wrote:

> Next week, I'll start implementation of UI tests for all screens.
> Emmanuel
> Jason van Zyl a écrit :
>> 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

View raw message