Thinking more about this. If the director receives both an -u <feature> and -i<feature> on the same <feature>, it will come up with a plan for an update if a newer version is available. So perhaps its as simple as doing that on all features (except the product itself).
Ideally, I think you should abandon the buckminster install and instead just use the director. An initial install of a fully configured buckminster can be made with one single director call using repeated -i <feature> [ -i <feature> ... ], i.e.,
director
-i org.eclipse.buckminster.cmdline.product
-i org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.pde.headless.feature.featuregroup
-i ...
-r <repo>
The trick for update is to just append '.feature.group' at the end of each feature. A call like this:
director
-u org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.core.headless.feature.feature.group
-u org.eclipse.buckminster.pde.headless.feature.featuregroup
-i org.eclipse.buckminster.pde.headless.feature.featuregroup
-u ... -i ...
-r <repo>
will result in an update if updates are available.
I do understand the need of that, but it raises a few issues depending on how and when this is triggered:
First Option:
This is a setting in the 'Manage Hudson' page as part of the Buckminster Installation configuration (a checkbox 'update automatically' or so). In this case the tool gets deleted and re-installed every time a build runs. This sounds a bit heavy to me but could be considered
Second Option:
this setting is part of a build job (update before execution)
That however is problematic. The managment of tool installations are a job of an admin whereas the job configuration is the responsibility of the job owner. The job should probably not be allowed to delete/alter the configuration given by the hudson admin (since the effects are global).
None of these I really like to be honest. It would be better to have the ability to actually update (or at least check for updates) instead of deleting and installing again. Is there a way (planned at least) to update buckminster, or is there a way for the director application to perform an update?
If not, would it be possible to check for updates to see if it makes sense to erase the existing installation and provision a new one?
That would match best with the workflows in hudson, since that way the first option could be used (make it part of the hudson configuration if the tool should be updated) while avoiding excessive network traffic.
The other installers (that download things) work in a similar way. When the tool is requested they check if it is already present. If so, they check if the download archive has been updated since the tool was installed. If so, they download the newer version and replace the old tool.