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
>
