SWTBot comes with a releng project and things generally work out of the box. See the {{SWTBotLink|Contributing| Contributing}} for how to build SWTBot.

SWTBot comes with a releng project and things generally work out of the box. See the {{SWTBotLink|Contributing| Contributing}} for how to build SWTBot.

−

===Installation from the GIT Repository===

+

===Installation from the Source Repository===

If you expect to be making changes to the SWTBot source code then the you should consider using GIT. The SWTBot Subversion repository is mirrored to a GIT repository. Although GIT has a higher learning curve than Subversion, you will find it easier to manage your changes and it will be easier for others to pull your changes.

If you expect to be making changes to the SWTBot source code then the you should consider using GIT. The SWTBot Subversion repository is mirrored to a GIT repository. Although GIT has a higher learning curve than Subversion, you will find it easier to manage your changes and it will be easier for others to pull your changes.

Line 11:

Line 11:

The GIT repository is at git://github.com/ketan/swtbot.git.

The GIT repository is at git://github.com/ketan/swtbot.git.

−

org.eclipse.swtbot.eclipse.ui contains two versions of the .classpath file. These are named _classpath.eclipse_3.4 and _classpath.eclipse_3.5. Copy one of these to .classpath, depending on which version of Eclipse is being used in your runtime environment. The build errors for this plug-in should go away. There are also two versions of the build.properties file. You will need to copy one of these too if you are going to do PDE builds or create your own update site.

+

If you clone this repository and import the projects into Eclipse, you will find a few errors. These can be fixed by running the ant targets '''materialize-workspace'''. See the readme file in the releng plugin for more.

−

+

−

org.eclipse.swtbot.junit4_x contains two versions each of .classpath and MANIFEST.MF in the META-INF directory. Depending on the version of JUnit you are using, copy one of _classpath.junit4_3 or _classpath.junit4_5 to .classpath and in the META-INF directory copy one of MANIFEST.MF_junit4_3 or MANIFEST.MF_junit4_5 to MANIFEST.MF. The build errors for this plug-in should go away.

+

−

+

−

Note that the org.hamcrest and com.thoughtworks bundles are checked into the SWTBot GIT repository and can be found in the org.eclipse.swtbot.releng project in externals/plugins. So you don't have to fetch these separately as you would if using the Subversion repository at eclipse.org.

Building SWTBot From Source

SWTBot comes with a releng project and things generally work out of the box. See the Contributing for how to build SWTBot.

Installation from the Source Repository

If you expect to be making changes to the SWTBot source code then the you should consider using GIT. The SWTBot Subversion repository is mirrored to a GIT repository. Although GIT has a higher learning curve than Subversion, you will find it easier to manage your changes and it will be easier for others to pull your changes.

If you clone this repository and import the projects into Eclipse, you will find a few errors. These can be fixed by running the ant targets materialize-workspace. See the readme file in the releng plugin for more.

Building an SWTBot Update Site

If you are using SWTBot in a project with many developers, and you want those other developers to run and maintain test, and you have made modifications to SWTBot then you will want to make those modifications easily available to the other developers. The easiest way to do this is to set up an update site that contains SWTBot with your modifications.

To create an update site, follow the instructions in MakingARelease.HOWTO in the org.eclipse.swtbot.releng bundle. Do not use the org.eclipse.swtbot.updatesite bundle. That is old stuff that creates an old-style update site (it predates Equinox p2). You should ensure unique versions, generally done by including your company name or project name in the version string.

The build.xml file contains the script for building the update site. However you must first ensure you have all the dependencies. A separate script is provided to install the dependencies. This script requires eclipse.sdk.url and eclipse.sdk.archive properties to be set to the location and name of the Eclipse SDK archive file. The best way to be sure you have all the properties set is to copy build.developer.properties.sample to build.developer.properties and edit as appropriate.

Once those are set, you can install the dependencies by running:

ant -file download-dependencies.xml download-dependencies

or just run the build.xml script which will run tasks in this script if necessary.