Re: [buckminster-dev] Hudson plugin and provisioning

[Johannes Utzig <mail@xxxxxxxxx>]

Hi,

today I finally had a chance to have a look at the auto 
installation/provisioning topic.
The good news is, there are 2 generic installers that could be used 
out-of-the-box as soon as I change the code to rely on Hudson's Tool 
infrastructure.
One installer can execute an arbitrary shell script, the other can 
extract an archive. This should initially be already enough to support 
custom buckminster installations.

Leaves the issue of a default installation that gets provisioned from 
eclipse.org:
-download a p2 director
-extract it
-use the director application to create a buckminster product of a given 
version
-install all features into the product

>  > 2. pick a version and install a default buckminster automatically 
> (pretty
>  > much all the features on the headless update site I would say)
>  >
> I like this. Question is how the builder would now what versions that 
> are available. Perhaps we could put up a file of some sort at 
> http://download.eclipse.org/tools/buckminster/, i.e. the parent folder 
> of our update sites where we list the versions and their respective 
> feature sets. That way, the Hudson plugin wouldn't need to hard wire the 
> sites and features, and it would give us freedom to move things around.

It took me quite a while to figure out how this is currently working 
with Ant/Maven/JDK because it's hardly documented and seems to be more 
magic than actual coding :)
Turns out that there is an updates folder on the hudson web server that 
contains several json files that feed the information into the specific 
installers:
https://hudson.dev.java.net/updates/hudson.tasks.Ant.AntInstaller.json

Unfortunately no hudson plugin has implemented such a thing yet (ant, 
maven, and JDK Tools are Hudson-Core functionality, not plugins) so I 
couldn't really find code examples on how to wire the pieces together so 
far.

Looks like it will be better to host the file with the version 
information directly on Hudson instead of eclipse.org to not dance out 
of line.
I will write again once I have a working implementation but it's 
somewhat more complicated than I thought so it might take some days still...

Best regards,
Johannes