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: <4533D8B4.8080108@erdfelt.com>
Date: Mon, 16 Oct 2006 15:08:36 -0400
From: Joakim Erdfelt <joakim@erdfelt.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060922)
MIME-Version: 1.0
To: continuum-dev@maven.apache.org
Subject: Re: contents of a 1.1 release
References: <a43524d00610161134s3b22f585re354d51120a1c9af@mail.gmail.com>
In-Reply-To: <a43524d00610161134s3b22f585re354d51120a1c9af@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

So we have ...

1) Profiles (should call this build-profile)
   This is a way to pre-define an environment type to execute the build
under.

    Example of build-profile against a maven 2 java project:
     * Choose the JDK to run with.
     * Choose the Maven version to run with.
    Example of build-profile against a c/c++ shell project:
     * Choose the c compiler.
     * Choose the architecture output.

    Set up your project to execute against 1 (or more) build-profiles.

    Combining this effort with the G-Build functionality would mean we can
    a build farm of available environments / platforms and then have a
single
    project build across all of those environments and produce a grid of
    success / failure for each build.

    Impact to user: Yes. Positive.
    Impact to developer: Yes.
    Impacts to code base: Huge.
    Impacts to Database Schema: Definite.

2) Refactoring for Workflows.
   This is an internal effort to make maintenance easier.
   Allows for extending the default continuum process / flows.
  
    Impact to user: No.
    Impact to developer: Large. Eases maintenance.
    Impacts to code base: Huge.
    Impacts to Database Schema: No.

3) Refactoring JDO Stores.
   Internal effort to reel in the mess that is continuum / jdo store
management.

    Impact to user: Yes. Upgrade problematic. Ease initial configuration.
    Impact to developer: Large. Make contributions easier.
    Impacts to code base: Yes.
    Impacts to Database Schema: Yes.

4) Downstream Dependency Change build-trigger.
   If a downstream dependency has changed, but the project code in SCM
has not, trigger a new build.

    Impact to user: Yes. Identifies potential problems before they
linger too long.
    Impact to developer: Minor.
    Impacts to code base: Minor, mostly new functionality.
    Impacts to Database Schema: No.

5) Proactive Dependency Build.
   Creates a side project / build using an in-memory pom that is a copy
of the project with all bleeding edge dependencies.
   This allows for proactive identification of potential dependency
upgrade problems.

    Impact to user: Yes. Proactive compile helps in development of project.
    Impact to developer: Minor.
    Impacts to code base: Minor, mostly new functionality.
    Impacts to Database Schema: No.

6) Database Schema Tool.
   We really should create a tool to aide in the management of the
database schema.
   So we can upgrade the database schema, or even create a blank schema
for a new jdbc datasource.
   Maybe even a tool to move the data from one jdbc source to another.

    Impact to user: Yes. Tools are good.
    Impact to developer: Minor.
    Impacts to code base: Minor, mostly new functionality.
    Impacts to Database Schema: Yes.

- Joakim Erdfelt


Jesse McConnell wrote:
> 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
>