Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

SWTBot/Maintaining SWTBot Versions For Your Team

< SWTBot
Revision as of 03:13, 1 July 2009 by Ketanpadegaonkar.gmail.com (Talk | contribs) (Initial content)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


SWTBot
Website
Update Sites
Community
Mailing List
Forums/Newsgroups
IRC
Contribute
Open Bugzilla tickets
Open Gerrit reviews
Browse Source
Continuous Integration


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 GIT 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.

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.

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 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.

You will need 'unzip' on the command path. If you are running Windows then you can download a compatible unzip implementation from http://gnuwin32.sourceforge.net/packages/unzip.htm.

Back to the top