As a follow-up to both Eclipse Feature Builds and Eclipse Update Sites it's also important to know that you can use Zed Builds and Bugs to actually host your Eclipse Update Site.

The Zed Builds and Bugs automated build server has an extension in the Zed Configuration File that allows you to host static HTML pages and serve them to users. The options included in this extension allow you to set up a publicly accessible web site. For our purposes, this is exactly what we'll use in order to host the Eclipse Update Site.

Let's take the example where we have installed Zed on a windows system in the default location of C:\Program Files\Hericus\Zed. We want to host the Eclipse Update Site under this location in the folder called EclipseUpdateSite.

When the user points their browser to our Zed server they will get the normal Zed login and the regular application. In order to get to our static content, we need to choose an extra path that they will use in their URL to get access to the static content. To keep things simple, we'll choose the path extension of /update/ for our update site.

Based on the above layout, we need to update the zed.xml configuration file to contain the following section:

	<ZedStaticHTML>
	   <ZedCustomHTML path="C:/Program Files/Hericus/Zed/EclipseUpdateSite/" requiresSession="false" url="/update/"/>
	</ZedStaticHTML>

The Zed server will need to be bounced to pick up this configuration file change, and when it comes back up we will be able to point our web browser to the url http://localhost:8081/update/ and access the files that are included in the directory c:\Program Files\Hericus\Zed\EclipseUpdateSite\ .

If you have multiple releases of a product, or multiple products that all require an Eclipse Update Site, you can use this technique to host all of them via the Zed Builds and Bugs server. You can either nest them all within a single directory and ZedCustomHTML entry, or you can use multiple ZedCustomHTML directives to point to each individual folder that is used.

For further details about the config file see the Zed Configuration File section in the documentation. It will detail how to protect access to the static HTML pages if required, for example.

With all of this in place, you now have full Continuous Integration capabilities for your Eclipse Feature Builds that will take them from source code to update site using just a few simple steps and features of Zed Builds and Bugs.

Last time we talked about how the new 2.1.1 release of Zed Builds and Bugs makes it easy to automate your Eclipse plugin builds. Following on with that theme, we'll show you this time how you can use Zed to take the compiled and packaged plugins and deploy them automatically to an Eclipse Update Site to publish your plugins.

Only a single build step is require to publish your eclipse feature as an update site, but before we get into the details of how to use it, we need to go back over the part about packaging your plugins as a set of features.

Eclipse plugin projects are typically grouped into feature sets so that it is easy to gather and distribute eclipse plugins as collections rather than as individual files or folders. This is especially important when working with an update site, as the update site deals with everything at the feature set level rather than at the plugin level. So in order to publish your plugs via an update site, you have to arrange them into a feature within your development environment first.

Once you have your feature, plugins, and have automated the plugin build for them, you can take the next step of adding the Eclipse Update Step to your build. When you do this, you'll see the following screen that will capture the details of how you want your feature published:

This step looks similar to the Eclipse Feature Build that we talked about previously, but is targeted to help you create your update site quickly and easily. Fill in the following fields:

• Feature Name This is the Eclipse feature that you would like to copy to an eclipse update site. It must have already been compiled correctly.
• Feature Category This is the name of your Feature Category and will be added to your site.xml file.
• Description This describes your Feature Category and will be added to your site.xml file.
• Update Site Root This is the full path to your eclipse update site. You may use build replacement variables for this setting.
• Create If Missing If the path defined by the Update Site Root field is missing, the Zed server will attempt to create it.
• Delete Update Site Contents Before Deploying If you are not sharing your update site folder with other projects, this can be a good way of ensuring that only the latest compiles are published to the update site.
• Site Description This is the overall description of your Eclipse update site. It will be set in the site.xml file.
• Error if Include Plugins Missing This allows you to trigger a build step error if any of the plugins defined by your Feature are missing. Sometimes you don't want this, and want to allow your Feature to be published even if some of the included features are missing.
• Error if Included Features Missing Eclipse Features can reference other Features. When this happens, a dependency chain is built up for each referenced feature. This option allows you to cause the build step to fail if anything in the dependency chain is missing. Sometimes you want to allow for missing features, though, and this option gives you that capability.
• Extra Files to Copy Sometimes you have files or plugins that you would also like to have copied over to the update site. This area gives you a free-form list of items that you would also like to have included in the copy process to build your update site.

Once you have finished defining the layout of your update site, save the build step, and your build will automatically create an Eclipse update site for you every time it runs.

With the introduction of Zed Builds and Bugs 2.1.1 release, the Zed Automated Build Server adds the capability to automate much of the process of creating feature builds for the Eclipse

Eclipse plugin projects are typically grouped into feature sets so that it is easy to gather and distribute eclipse plugins as collections rather than as individual files or folders. Eclipse allows the user to enable/disable plugins at the feature level as well, so that you can tailor your Eclipse working environment to the task at hand and optimize the amount of memory required by your Eclipse workspace at any one time.

Zed Builds And Bugs automated build server now includes specific build steps to help you to build your Eclipse plugin projects when they are grouped into Feature projects. Full details on this can be found in the Zed Documentation on Eclipse Builds or in the individual Eclipse Feature Build Step and the Eclipse Update Site Build Step documentation.

The Eclipse Feature Build Step looks like this when you add it to your Zed Automated Build Project:

On this screen, use the fields as follows:

• Feature Name Enter the name of your Eclipse feature.
• Eclipse Base Dir This is the directory where the Eclipse installation is located. The Zed automated build system uses this Eclipse installation to manage the build of your feature, so any plugins required by your project should be present within this Eclipse installation.
• Generate build.xml Files The Zed automated build system will handle generating all of the Ant build.xml files for you so that your feature is compiled properly. If you have customized these build.xml files, you can turn this option off so that the Zed automated build system will not overwrite your files.
• Standard Targets There are several standard targets provided with the generated Ant build.xml files. Each of these is displayed here with a checkbox to let you turn these targets on or off. At a minimum you will probably need build.jars and either build.update.jar (for an eclipse update site) or zip.distribution (for a CD distribution of your product).
• Custom Targets This allows you to add in any extra Ant build targets that you would like the compile to include. These will be added after the Standard Targets that are referenced.
• Update build.xml Files The generated build.xml files have some settings that we consider sub-optimal. The defaults generated for this build step will help you to adjust those settings. This will do a standard Search & Replace for all build.xml and MANIFEST.MF files within your feature project and dependent plugins.

Handling all of the background work for you and resolving your project dependencies saves you time and headaches while creating automated builds for your eclipse projects. Simply group your plugins into features and let Zed Builds and Bugs handle the automation for you.