Draft Build Specification

This is the place to capture the requirements for a automated build process for the Higgins project.

Initially the builds will only be available as Java Eclipse plugins.

In the long term we've publicly committed to also support these three package managers:

• RPM & Debian (for Suse, Red Hat, Debian, Ubuntu)
• OSX
• Windows

The download pages need to make it clear what processors the binaries are for. (Note The Eclipse folks said that they are working on automated build scripts for the Eclipse IDE to target RPM and Debian package managers. Don't know about OSX.)

What we need for the Eclipse download page:

• 1)We need automated build scripts for each separate "singleton" Higgins component that execute on build.eclipse.org (I think that's the name of the build server) and create their own separate sections on the download page(s). What I mean by singleton is a component of which there is one and only one (shown in the diagram as NOT having a second gray box behind it and slightly offset).

There should be NO components on the Higgins download page that don't line up with the Core Component Architecture. See the Component Inventory http://wiki.eclipse.org/index.php/Component_Inventory. Each element in the Component Inventory needs to be automatically built (with javadoc) and automatically tested (on build.eclipse.org) in three variants (daily, stable and release.)

• 2) Similar to 1) above, for components of which there will be N instances (non-singletons) (E.g. Context Provider plugins, or I-Card Provider plugins, or Token Provider plugins) there needs to be separate build scripts for each one. And a separate place on the downloads page.

• 3) Version numbers should line up with milestone (we're in M0.6 at present).

• 4)The .psf files (one for each Higgins component) also need to be made available.

• 5)To implement such download structure first of all we need to define the folder's structure for our downloads. IThere are two types of folders in our downloads structure: "leaf" for each "singleton" components and "node" for each non-singleton components (including our main downloads page).

Consider we have such folder structure for our downloads:

• downloads - root downloads folder - node
• idas - idas downloads folder -leaf
• contextProviders - context providers downloads folder - node
• jena - downloads folder for jena based provider - leaf
• xx - downloads folder for xx provider - leaf
• hbx - hbx downloads folder - leaf

Note that there are more nodes and leaves (see http://wiki.eclipse.org/index.php/Component_Inventory ). Also in some cases multiple build targets, etc.

In such case each "node" downloads folders (including root downloads folder) will contains similar index.php which will look in subfolders for example for some file with specific structure) in order to decide which of them should be included in the links to descendant components. At the same time each "leaf" folder (idas, jena, xx, hbx) will contains build results for this "leaf" component similar to what we now have for our old higgins stuff (there we will use .php file generated by each particular build script).

Next action items:

• Determine the target CPU list is (x86, plus others TBD by dev call discussion)

• Present a template for the downloads page with dummy content. If Valery makes another pass on creating the template for this page, I will update the static content.

• Create a build script for org.eclipse.higgins.idas that will run on build.eclipse and that will, every night, build a new version. As components are added (e.g. the org.eclipse.higgins.sts that MikeM is going to contribute) we will create scripts for them.

• HBX also lines up with the component architecture and should be covered by the nightly build process. HBX needs to be on its own separate download page as there will be many end users who will only need this piece. This page needs to be able to be used by somjeone who is not an Eclipse engineer. There should be a link to this page from the main downloads page.

• (Jena-based) Context Provider will be the second component that is built every day