Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <45364AD5.4020300@venisse.net>
Date: Wed, 18 Oct 2006 17:40:05 +0200
From: Emmanuel Venisse <emmanuel@venisse.net>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: continuum-dev@maven.apache.org
Subject: Re: contents of a 1.1 release
References: <a43524d00610161134s3b22f585re354d51120a1c9af@mail.gmail.com>
 <4534EEB5.9040500@venisse.net>
 <644EE206-1C44-4E64-BD3B-837D4D014AA0@apache.org>
 <029CC3A6-745B-4F27-92FC-531A3D0F8B43@maven.org>
In-Reply-To: <029CC3A6-745B-4F27-92FC-531A3D0F8B43@maven.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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
>>
> 
> 
> 
>