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
>
