[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.buckminster] Buckminster updating / change-list generation



Greetings folks,

I'm relatively new to Buckminster, but enthusiastic! Please excuse me if I don't wield the vocabulary properly or don't grok some of the concepts.

I've read in this newsgroup various postings about extending Buckminster to allow for updating an existing workspace (presumably via a cquery) and generating change-lists as a side effect. Such a functionality would be useful for CI framework integration - the goal being to maintain a workspace and bump it to the latest code, recording changes, comments, authors, etc, then rebuild and run tests. In my case, integration with Hudson is most immediate, but I imagine that other CI frameworks would benefit from similar functionality.

Would something like the following make sense:

* add IComponentReader.update(IPath location, Resolution resolution, MaterializationContext ctx, IUpdateDeltaObserver observer, IProgressMonitor monitor)
* add IComponentReader.canUpdate(); ??
* create IUpdateDeltaObserver which will get update events based on what is being updated.
* create UpdateJob that is designed to update a materialized workspace and record update events into a file based on configuration params
* create UpdateCommand that is wired to buckminster update <cquery> with appropriate options to control placement, naming etc. of the change-list xml output
* Optional extensions
** allow for a quick-as-possible (early bail on first change detected) probe if an update would change something (IComponentReader.needsUpdate() and an additional command?)
** allow for an option to run the update, gather the deltas, but not actually do anything (additional boolean arg to IComponentReader.update?)


Questions:

* Would this be a reasonable pattern for all readers? I suppose, to start, some readers could update silently or noop & log on the update??
* Is the Reader the proper level of abstraction for differentiating the update functionality?
* Would it be better to offer the update as a set of parameters to the materialization Job/Command rather than a separate command entirely (enforce identical resolution and other workflow phases)?
* Is this the right direction?


If it's cool with the powers that be, I'd be happy to roll up my sleeves once a direction is agreed upon.

Cheers,

pete