[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Hudson plugin and provisioning
|
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
