Nick Boldt [http://community.jboss.org/people/nickboldt] modified the document: "Manage SWTBot bits used by builds and developers" To view the document, visit: http://community.jboss.org/docs/DOC-16087 -------------------------------------------------------------- JBT/JBDS builds and JBT/JBDS SWTBot tests developers have to use the same version of SWTBot to ensure consistency. Current version of SWTBot release used is specified in the target platform definition files (*.target) stored in SVN repository here: http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/ http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/. There are two files available. *Multiple.target* contains all the source URLs from whichc the target is built. *Unified.target* contains the same IUs (installable units) but swaps out the URLs for our own JBoss mirror, located here: http://download.jboss.org/jbosstools/updates/target-platform/latest/ http://download.jboss.org/jbosstools/updates/target-platform/latest/ Open the .target file in  your favourite Text or XML Editor, and search (CTRL-F or /) for "swtbot" to find the relevant IUs and their versions. ".feature.group" means "this feature and all its contained plugins". h5. Updating JBoss Tools Hudson Builds To The Latest SWTBot Release When SWTBot needs to be updated, verify your tests will still work with the latest release: 1. Compile complete SWTBot test suite in your workspace (using M2Eclipse) or via commandline (using Tycho) to verify updated SWTBot release does not break your tests.* If there are compilation errors, fix them or report them in JIRA. Test locally before committing changes to the tests back to SVN 2. Update SWTBot target file to specify proper SWTBot release version and commit it to SVN. 1. The easiest way to do this is to do a Maven build in the target-platform directory and generate the target platform repo locally. * cd ~/trunk/build/target-platform; mvn3 clean install -P get.*local.target* 2. This will fetch all the contents from the target platform, and update the .target files to use the versions found in the repo you generate locally. You can also update the .target files by hand, if you prefer, but the automated approach is easier and less error-prone. 3. As a result of running a build of the target platform locally, you can now *OPTIONALLY* use that repo instead of the remote one when running your builds. To activate this *local.target* repo, do this:* cd ~/trunk/build/parent; mvn3 clean install -P *local.target* * cd ~/trunk/build; mvn3 clean install -P*+componentToBuild+*,*local.target* (where +*componentToBuild*+ may be as, archives, esb, ... or as-bootstrap, archives-bootstrap, esb-bootstrap, ...) While a build will run automatically in response to your committed changes, you can also kick one manually to save time: * http://hudson.qa.jboss.com/hudson/job/jbosstools-3.2.0.Beta2.target-platf... http://hudson.qa.jboss.com/hudson/job/jbosstools-3.2.0.Beta2.target-platf... h5. Updating JBoss Developer Studio ("Uberbuilder") Hudson Builds To The Latest SWTBot Release 1. Create a collection of new zips of the for the updated releases. 2. Create new md5sums. 3. Publish them somewhere that Hudson can see them 4. Update the properties file that JBDS uses to access them: * http://svn.jboss.org/repos/devstudio/trunk/releng/org.jboss.ide.eclipse.r... http://svn.jboss.org/repos/devstudio/trunk/releng/org.jboss.ide.eclipse.r... h5. Communication Strategy, or, Letting People Know About Changes It's important to let others know that you've updated the SWTBot baseline against which everyone's tests will be run. Send an email to the mailing list here: * mailto:external-exadel-list@redhat.com external-exadel-list(a)redhat.com -------------------------------------------------------------- Comment by going to Community [http://community.jboss.org/docs/DOC-16087] Create a new document in JBoss Tools at Community [http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]