When mirroring eclipse repositories, my main idea is to keep the path structure of the original repository URL. For instance, if you are using something like

http://download.eclipse.org/releases/juno

the mirror should differ only for the base url, e.g., something like

/home/myhome/eclipsemirror/releases/juno

This is useful if the p2 repositories you use for materializing your target platform are parametrized with respect to the base URL. For instance, I’m using Buckminster to materialize my target platforms (see also this post), and in my RMAP files I have something like

You see that the URLs are parametrized over the property eclipse.download (which defaults to http://download.eclipse.org). If I mirror those repositories keeping the same structure

then, switching to my local mirror for target materialization it’s just a matter of passing for the property eclipse.download the URL of my local directory, e.g., file:/home/bettini/eclipsemirror, without even changing my RMAP files.

So let’s start mirroring! We need to define an Ant script for the p2 antRunner.

For instance, for mirroring the whole orbit repository (with that particular drops version) we create this script, let’s call it mirror-orbit.xml:

Note that we keep in the target dir the same path structure of the original repository.

Since these Ant tasks need to be run via the Eclipse antRunner application, you need a full installation of Eclipse on the machine that will run the task. And you run this task with a command line like the following

1

2

3

4

/path/to/eclipse-noSplash\

-application org.eclipse.ant.core.antRunner\

-buildfile mirror-orbit.xml\

-Dtarget.dir=$HOME/eclipsemirror

Of course you can choose any target dir; the idea is however to always use the same target dir so that all repositories will be mirrored in that path.

Mirroring an entire repository might not always be the case, especially for Juno main release repository, which is quite huge. But you can specify in the Ant task the installable units you’re interested in; then, the p2 task will only mirror those installable units (and all its dependencies). For instance,

XHTML

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

<project name="Create Mirror"default="create-mirror"basedir=".">

<target name="create-mirror">

<p2.mirror source="http://download.eclipse.org/releases/juno">

<destination location="${target.dir}/releases/juno" />

<iu id="org.eclipse.sdk.feature.group" />

<iu id="org.eclipse.equinox.executable.feature.group" />

<iu id="org.eclipse.emf.sdk.feature.group" />

<iu id="org.eclipse.emf.query.sdk.feature.group" />

<iu id="org.eclipse.net4j.sdk.feature.group" />

<iu id="org.eclipse.net4j.db.feature.group" />

<iu id="org.eclipse.emf.cdo.sdk.feature.group" />

<iu id="org.eclipse.draw2d.sdk.feature.group" />

</p2.mirror>

</target>

</project>

This task will mirror all the features that should let you define a target platform for RCP development with EMF and CDO.

NOTE: if you try to mirror org.eclipse.platform.sdk from the releases/juno repository, you will see that it will actually mirror the whole repository! (see also this forum post).

If you get some warnings during the mirror about unsolvable dependencies, you can ignore them: basically those dependencies are in a different repositories, and probably you will mirror those repositories too later.

Of course you can use several p2.mirror elements in the same Ant task. For example, this is the one we use in Emf Components, to have a mirror for our target platform: it also mirrors Swtbot and Xtext SDKs:

Final warning: it might take some time for the mirror task to complete (usually hours depending on your connection and download.eclipse.org load) and it will also take some hard disk space (for the above mirror it takes about 2 Gb).

You may have to experiment a bit to get all the features you need in the mirror; for instance, I didn’t know about the draw2d above, but I had to add it since during target materialization that feature was requested by some other feature. If you’re lost about that, you can always mirror the whole thing

One of the new cool features which came with Xtext 2.3.0 is a wizard which generates all the artifacts to build your Xtext DSL project with Buckminster; this will allow you to easily build your Xtext project p2 site and also to build your project and its tests headlessly (e.g., from the command line, and, more importantly from within a continuous integration system like Jenkins).

This new feature was not advertised much, nor documented, so I decided to write a tutorial about that, also with the permission of the developer of this feature Dennis Hübner.

In this tutorial I will show how to

create the p2 repository from the IDE

build your project (and run the tests) headlessly from the command line (through ant)

build your project (and run the tests) headlessly in a continuous integration system like Jenkins

In the end, I will also try to describe/explain all the Buckminster files that the wizard created for you, so that one can customize them.

Create an Xtext project

So, first of all, let’s create a simple Xtext hello project; for this example I will use the following settings:

project name: org.xtext.example.hellobuck

name: org.xtext.example.hellobuck.HelloBuck

extension: greetings

check “Create SDK feature project”

and then, of course, we generate Xtext artifacts.

The DSL is basically the standard Greetings DSL; in this case, I’m using the JvmModelInferrer to generate Java classes from “Hello” specifications. Indeed, the DSL itself is not important in this tutorial. I’ve also added two Junit tests in the corresponding org.xtext.example.hellobuck.tests project:

Note the org.xtext.example.hellobuck.tests.launch Launch configuration that Xtext created for you (which basically runs all the Junit tests in this project. We will see how this will be used later.

Use the Xtext Build with Buckminster Wizard

Now we can use the Xtext wizard “Build with Buckminster”: New => Other => Xtext => Continuous Integration => Build with Buckminster:

You will have to specify the sdk feature of your Xtext project (that has been created by the Xtext new project wizard); the releng and site projects will have predefined names. For the Buckminster installation directory you have 3 choices:

if you have already an headless installation of Buckminster in your system you can specify the path;

you can install it using the link in the dialog

you can leave that path empty and specify it later in the build.ant generated file (or pass it on the command line when invoking ant)

In any case, specifying the headless Buckminster installation path is only useful if you intend to build your projects headlessly with ant (it is not requested for building in the IDE, nor if you plan to build it with Jenkins by setting job using the Buckminster Jenkins plugin, as we will see later).

Before pressing Finish, we also want to specify the tests to launch during the headless build, so we press the button Add and we select the launch configuration in the .tests project which the Xtext wizard created for us.

If you want to build an existing Xtext project and you do not have that launch configuration, all you need to do is to simply create a new plain Junit launch configuration from the IDE, for instance, to run your existing Junit test suite, and save it in the .tests project yourself. You can also configure the headless build to run tests later on.

When the wizard finishes, you will end up with two additional projects

org.xtext.example.hellobuck.buckminster with all the Buckminster (CQUERY and RMAP, build.ant, etc.) files to build your project headlessly;

org.xtext.example.hellobuck.site which is a feature project to create the p2 repository for your Xtext project.

Build the p2 repository from the IDE

Although the .buckminster project created by the wizard is thought to be used in an headless environment, the .site project is useful also to build the p2 repository from the IDE itself! Indeed, if you created an old style update site, you could build the update site from the IDE itself. But if you switched to the new category.xml format, then building the corresponding p2 repository from the IDE is not straightforward.

If you want to run Buckminster from Eclipse, you first need to install it in the IDE of course, by using this repository: http://download.eclipse.org/tools/buckminster/updates-4.2

Before creating the p2 repository, you may want to tweak some Buckminster properties, for instance, you may want to create a buckminster.properties file in the .buckminster project (or in the .site project) like the following

1

2

3

4

5

6

7

8

9

10

# Where all the output should go

buckminster.output.root=${user.home}/tmp/hellobuck/build

# Where the temp files should go

buckminster.temp.root=${user.home}/tmp/hellobuck

# How .qualifier in versions should be replaced

qualifier.replacement.*=generator:lastRevision

target.os=*

target.ws=*

target.arch=*

so that Buckminster will generate all its artifacts in the tmp/hellobuck directory of your home folder.

We now right click on the .site project, and select Buckminster => Invoke Action… , we select site.p2 action, and optionally refer to the buckminster.properties file

When the action finishes, you will file the p2.site in the directory $HOME/tmp/hellobuck/build/org.xtext.example.hellobuck.site_1.0.0-eclipse.feature/site.p2/

Build with ant

The wizard created for us, in the .buckminster project a build.ant file that we can use to build the project, run the tests, and create the p2 repository with ant

Note that this file has the location of your Buckminster headless installation path hardcoded (recall the wizard we used before for creating Buckminster projects); if that is not correct, you can still pass this information to ant when invoking it

Shell

1

ant-Dbuckminster.home=<PATH>-fbuild.ant

This ant script will build your project in the directory buildroot which will be created in the directory where all your projects are located (e.g., in the workspace or in another path); in particular it will

materialize the target platform for your project (the first time you run it), and this requires an Internet connection and might take some time

build your projects

run the Junit tests

build the p2 site repository

This should be the output (where WORKSPACE is actually the location of your projects):

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

Buildfile:WORKSPACE/org.xtext.example.hellobuck.buckminster/build.ant

cleanup:

buckminster:

[echo]IMPORTANT:Populating an empty target platform may took over10minutes.

IMPORTANT: there’s a bug in the currently generated build.ant file, which prevent you from building with ant in Windows; until the fixed version of the wizard is released, you need to make sure that the build.ant has the right contents, as in this example source.

Build with Jenkins

To build your Xtext project in Jenkins you can either create a Job which uses ant and the build.ant script, or create a Job which uses the Buckminster Jenkins plugin (I’ve also blogged about that). I will detail both ways. Both jobs have in common the access to the git repository

A Job using ant

This requires that you configured an ant installation in your Jenkins, and that you already have a working version of Buckminster headless in Jenkins; you need to specify them in the ant build step configuration (the screeshots, of course, refer to the paths and values for my Jenkins installation):

then, we configure post build actions to archive both the artifacts (the p2 repository) and the Junit results:

A job using Buckminster plugin

To configure a Buckminster build step, we prepare a text file in the .buckminster projects with the Buckminster commands to execute (we take inspiration from the commands.txt file that the wizard created), we call it jenkins-commands.txt:

Then we configure a build step (this relies on a Buckminster installation that we have already configured in Jenkins), note that we refer to the jenkins-commands.txt we created above (an alternative would be to copy the commands directly in the text area “Commands”):

To configure the post build actions, since we used different output paths, we have to specify them accordingly (in particular, we have not used the output directory buildroot, thus the default will be used):

Details and Customization

It may be interesting to learn more about the files that the Xtext Buckminster wizard generated for you (at least, I personally found instructive to look at them, and learned something about Buckminster most of which I described in another post of this blog). The details might also help you if you need to customize the generated files.

The .buckminster project contains a Component Specification (CSPEC), buckminster.cspec, which looks like

thus, due to its dependencies, it represents the target platform for your Xtext project. If your Xtext project required some further specific dependencies to build and test, this is the place to express them!

For instance, in an Xtext project of mine, Xsemantics, I run also some SwtBot tests, which also rely on pde, thus, the dependencies in the corresponding .buckminster project’s buckminster.cspec look like

To materialize components and dependencies with Buckminster, you need a Resource Map (RMAP), and the wizard created two maps: one containing p2 repositories location (for materializing the features of your target platform), called projects-platform.rmap and one for binding your projects to the workspace (when building headlessly), called project.rmap.

This basically tells Buckminster to take all Xtext stuff (including additional components like Google Guice and Antlr) from the Xtext main repository, and to use the main Eclipse Juno release repository for everything else. However, it also redirects to project.rmap for resolving the main Buckminster component of our project org.xtext.example.hellobuck.buckminster.

Again, if your target platform needs additional features from different sites, this is the place where to express them; reusing the example above which also needed SwtBot the rmap would also have these additional stuff:

This rmap assumes that all the Eclipse projects of your Xtext project are in the same base directory; if this is not the case, because you split them, for instance, in plugins, features, doc, etc. directories, then you need to tweak this rmap accordingly, for instance, again, taken from Xsemantics,

Then, you have to Component Query files (CQUERY): projects-platform.cquery, to materialize the target platform, and project.cquery, to materialize your projects in the workspace. The first one could also be used in the IDE to actually materialize the target platform in your workspace (instead of using a target definition file); the second one is useful when building headless.

Note that this cquery has an advisor node to skip .source components: thus, the materialized target platform will not contain the sources for all the features. This is useful headlessly to reduce the time to materialize the target platform. But if you use it also for materializing the target platform in the IDE, then sources are useful to inspect Java classes, and you might want to remove this advisor node (or simply create another cquery only to be used in the IDE, without that advisor node). This query refers to projects-platform.rmap.

As it usually happens when using Buckminster, the cquery for materializing the projects in the (headless) workspace refers to a single feature project which, transitively refers to all the bundles and additional features of your application. Usually, this is the feature project for building the p2 repository, like in this case.

“But wait! the site feature project does not refer to test projects, since I do not want to include them in my p2 repository! So, how can Buckminster run my tests headlessly if they are not materialized?”

If you look at the feature project .site, you will note that it contains a Component Extension (CSPEX) which allows to extend the automatically inferred Component Specification for the feature project with additional specifications. In this case the buckminster.cspex contains

You see that this specification adds a dependency to the org.xtext.example.hellobuck.tests project, so that, when Buckminster materializes org.xtext.example.hellobuck.site, and its dependencies, it will also materialize org.xtext.example.hellobuck.tests. You can use this technique to materialize additional projects; for instance, in from Xsemantics, I have a main feature for tests, and a tests project for each example, thus buckminster.cspex reads as follows

which includes the .sdk feature of your project (Remember: when building the site.p2 on a feature project with Buckminster, you will build a p2 repository NOT for the very feature, but for the included features), and the category.xml to give categories to your features in the p2 repository:

XHTML

1

2

3

4

5

6

7

8

9

10

11

<?xml version="1.0"encoding="UTF-8"?>

<site>

<feature id="org.xtext.example.hellobuck.sdk"version="0.0.0">

<category name="main"/>

</feature>

<feature id="org.xtext.example.hellobuck.sdk.source"version="0.0.0">

<category name="main.source"/>

</feature>

<category-def name="main"label="Hellobuck"/>

<category-def name="main.source"label="Source for Hellobuck"/>

</site>

Note that the .sdk.source feature is not a “real” feature project in your workspace, but, by default, Buckminster will automatically build a source jar for all your features and bundles.

That’s all! Many thanks to the author of this wizard, Dennis Hübner, for making it and for many suggestions!

This post was inspired by another blog post I had found on the web when trying to build a p2 site corresponding to a target platform defined for my projects. For an year I’ve been using Buckminster for building my Eclipse projects (especially when I had problems building my Xtext projects with Maven/Tycho, so that I decided to switch to Buckminster).

Having a p2 site for the current platform has some advantages, I guess:

Building RCP products will be easier (Buckminster relies on p2 directory, and all the bundles for building the product will be searched for in p2 sites);

It represents a (local) mirror for the target platform (for easier access).

This tutorial will show how to materialize the target platform and build the p2 sites

in the IDE,

headlessly from the command line through ant, and

headlessly in Jenkins.

For the IDE you will need to install Buckminster main features in Eclipse, using the update site http://download.eclipse.org/tools/buckminster/updates-4.2.

NOTE: sometimes Buckminster’s cache in the IDE becomes stale, and you might experience errors about missing components; you might want to restart Eclipse and usually this makes the problem go away.

Why not the Target Editor?

I experienced many problems when using Eclipse Target Editor (based on p2 sites); I found it quite unreliable, especially for modifying a target definition, for updating a target definition (the Update button works 1 time out of 10); moreover, it takes some time for the target to be resolved (every time you reopen a target definition with the editor).

Furthermore, when you define a target for building RCP products, then you usually want to be able to build for several platforms, not only the current one; in these cases you have a checkbox to select (“Include all environments“):

But in that case, you must give up on “Include required software”, and this might get you into troubles about missing bundles, when building your product, if it needs to include more involved features (besides the standard “Eclipse RCP SDK” and “Eclipse Platform Launcher Executables”); for instance, if your product needs also EMF Eclipse Modeling Framework SDK (which is required when using Eclipse RCP 4.2).

Defining a target platform the “Buckminster way” does not have this limitation (and, honestly, once you get familiar with that, it’s much faster than using the target editor).

Defining a Target Platform with Buckminster

Although Buckminster is able to materialize a target platform starting from a standard target definition, it also provides an alternative way:

Define a component which represents all the target features by creating a project and a custom CSPEC; this CSPEC basically declares the target features as dependencies

Define a resource map (RMAP) which tells Buckminster where to find these dependencies; we will use of course official Eclipse p2 site repositories for these dependencies

Define a component query (CQUERY) which materializes the component representing the target platform

In our example, this project is called bucky.example.rcpemf.target (it is a generic project without any nature). This is the project where we will define all Buckminster files (CSPEC, CQUERY and RMAP). In this project we define the component specification: buckminster.cspec

Here we use the name of the features for our target platform. (NOTE: org.eclipse.rcp and org.eclipse.rcp.source, together, correspond to Eclipse RCP SDK.)

The rmap (which we call target-platform.rmap) is defined as follows:

XHTML

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

<?xml version="1.0"encoding="UTF-8"?>

<rm:rmap xmlns:rm="http://www.eclipse.org/buckminster/RMap-1.0"

xmlns:bc="http://www.eclipse.org/buckminster/Common-1.0">

<rm:property key="projects.location"value="${workspace.root}" />

<rm:searchPath name="juno-releases">

<rm:provider componentTypes="osgi.bundle,eclipse.feature"

readerType="p2"source="false"mutable="false">

<rm:uri format="http://download.eclipse.org//releases/juno" />

</rm:provider>

</rm:searchPath>

<rm:searchPath name="juno-updates">

<rm:provider componentTypes="osgi.bundle,eclipse.feature"

readerType="p2"source="false"mutable="false">

<rm:uri format="http://download.eclipse.org/eclipse/updates/4.2" />

</rm:provider>

</rm:searchPath>

<rm:searchPath name="local-source">

<rm:provider componentTypes="eclipse.feature,osgi.bundle,buckminster"

readerType="local"mutable="false">

<rm:property key="buckminster.mutable"value="false" />

<rm:uri format="{0}/{1}">

<bc:propertyRef key="projects.location" />

<bc:propertyRef key="buckminster.component" />

</rm:uri>

</rm:provider>

</rm:searchPath>

<rm:locator searchPathRef="local-source"failOnError="false" />

<rm:locator searchPathRef="juno-releases"failOnError="false" />

<rm:locator searchPathRef="juno-updates"failOnError="true" />

</rm:rmap>

In our case we use the two main Eclipse p2 repositories (if the features you need are available from other p2 repositories, you will need to provide p2 reader types for these repositories as well). We will not use regular expressions for specifying the source p2 repositories, since there are no ambiguities in this example; instead, we simply specify the locators in the order we desire (preferring juno release site to juno updates). Note that we also have a search path for local sources. This is useful for building headlessly, so that Buckminster is able to find, resolve and bind to the workspace our own projects.

Finally, the component query (which we call target-platform.cquery) is defined as

Thus we request the component corresponding to our project bucky.example.rcpemf.target. Note that we specify that we are not interested in any specific architecture, so that we will have a target platform for all platforms/environments/architectures. Note also that in the cquery we reference the above defined rmap.

Materializing the Target Platform

We can now materialize the target platform so defined by opening the target-platform.cquery with Buckminster corresponding editor:

WAIT: If you pressed the “Resolve and Materialize” now, Buckminster would materialize the target platform in the directory tp of a hidden project in your workspace (.buckminster). Moreover, by default, the created target platform is based on the configuration of the currently running Eclipse instance. If you want to start from a plain and empty platform (just like you do with a standard target definition with the target editor), there are a few more steps to perform:

Create an empty target platform manually that contains one single and empty directory.

Set this target platform active.

A subsequent resolution/materialization will use that platform.

You can specify any directory of your filesystem, in any case, make sure the directory you choose already exists.

Click on “Variables…” scroll down and select “workspace_loc” and then type TP in the Argument: field

This procedure is shown by the following screenshots.

NOTE: these additional steps are not required when building headlessly

Once you pressed Finish and set this new target as the active target platform, you’re ready to materialize the cquery from the cquery editor. Of course, it might take some time for downloading all the features. Once the materialization is finished, if you followed the above procedure and created a general project TP in your workspace, you can see the materialized target platform

Create a feature for the p2 site for your target platform

Once the target platform is resolved (you can also have a look at the current new target platform from the Eclipse preferences), we are ready to create a feature that we use to create the p2 site corresponding to our target platform.

We thus create a new feature project, that we call bucky.example.rcpemf.target.site, and we initialize it with all the bundles (plugins and fragments) of the current target platform (if you have other bundle projects in your workspace, make sure to unselect such additional workspace projects)

Before creating the p2 site, you may want to create a buckminster.properties (e.g., in the main project bucky.example.rcpemf.target) where we set some properties for Buckminster (e.g., that we want to build a site for all environments, and that we want the site to be created in a specific folder, in this example /tmp/bucky):

1

2

3

4

5

6

7

8

9

10

# Where all the output should go

buckminster.output.root=/tmp/bucky/build

# Where the temp files should go

buckminster.temp.root=/tmp/bucky

# How .qualifier in versions should be replaced

qualifier.replacement.*=generator:lastRevision

target.os=*

target.ws=*

target.arch=*

We are now ready to build a p2 site for this feature with Buckminster:

If you used the same property file, you can find the site.p2 in /tmp/bucky/build/bucky.example.rcpemf.target.site_1.0.0-eclipse.feature/site.p2/ .

The p2 site you’ve just created could already be used, for instance, for building your RCP product with Buckminster through the p2 director. However, as it is, it contains only bundles, no (installable) features, thus it cannot be used, for instance, as a mirror for your target platform… see the next section

Create a feature for the p2 MIRROR site for your target platform

We create a new feature project bucky.example.rcpemf.target.mirror.site, and, as before, we initialize it with all the bundles (plugins and fragments) of the current target platform (if you have other bundle projects in your workspace, make sure to unselect such additional workspace projects); but this time, once the feature project is created, we also add to the feature.xml all the features that we used to create our target platform:

Let’s run the action site.p2 (using the same buckminster.properties file) on this new feature project. This time, we will end up with a p2 site with all the installable features of our target platform! You can verify this by using the Eclipse install new features menu and using as repository the one just created (if you used the same output directory it will be located at /tmp/bucky/build/bucky.example.rcpemf.target.mirror.site_1.0.0-eclipse.feature/site.p2/).

Even more, you might create a target definition file, open it with the Eclipse target editor, and create a target definition using your local mirror!

Headless execution from the command line

If you want to materialize the target platform and build the p2 site from the command line, you need to install the headless version of Buckminster.

Note we reuse the same rmap we saw before. This way, during the materialization of the mirror site feature, possible additional dependencies will be resolved by Buckminster and added to the target platform;

perform the site.p2 action (before we also perform a buckminster.clean) on the component of the mirror site

We then write an ANT file, build.ant, in the project bucky.example.rcpemf.target, as follows (this was inspired by the one generated by the Xtext wizard, developed by Dennis Hübner – I’ve blogged about that, and from the one that can be found here):

XHTML

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

<?xml version="1.0"encoding="UTF-8"?>

<!--

Buckminster Headless - build

buckminster.home must be specified on the command line, e.g.,

ant -Dbuckminster.home=/home/bettini/buckminster -f build.ant

Properties:

WORKSPACE Eclipse workspace location, or hudson job workspace

build.root Where to build? WARNING: This folder will be cleaned up, so do not point to user.home or something important

You need to execute Buckminster twice because of some conflicting bundles (see the discussion here) which cause problems if you attempt to run everything in one shot; if you did not separate the steps, you would get something like

If you want to access your remote Ubuntu machine with VNC, in particular by tunnelling through ssh, there is already some documentation which can be found here. However, at least for me, the procedure explained there does not work out of the box. So here’s what I had to do to make it work.

First of all you need to install in the machines the following packages:

remote machine: xvfb x11vnc openssh-server

local machine: xtightvncviewer openssh-client

Then, the script to run on your client machine to access the server has to be slightly modified as follows

Shell

1

2

3

4

5

6

7

#!/bin/sh

ssh-C-f-L5900:localhost:5900USER@REMOTEIP\

x11vnc-safer-localhost-nopw-once\

-auth/home/USER/.Xauthority-display:0-create\

&&sleep5\

&&vncviewer localhost:0

where you will have to replace USER with your user on the remote machine, and REMOTEIP with the address of your remote machine.

Basically, the changes I had to make to the original script were to add the -auth command line option specifying the path to the .Xauthority, and the command line option -create to actually start an instance of the X server on the remote machine.