Wednesday, June 16, 2010

Headless Build for Beginners - part II

Building through features

Plug-ins are rarely required to be build in isolation. The nicer way of building them is through features. Of course, features are more useful from distribution and deployment point of view. A feature is build the same way as a plug-in. Include the required plug-ins in the feature.xml and generate the build.xml from file (right-click and choose PDE Tools). Now launch the feature build.

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-workspace-path>\<feature-project-path>\<build-xml-path>

java -jar C:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile C:\workspace\com.example.helloworld.feature\build.xml

Note that build will fail if the included plug-ins do not have the build.xml generated for them. This is not a likely scenario and definitely not the way it is done. But let it be for time being. Generate the build.xml for all the plug-ins for build to succeed. Later on we will see how it can be done without it.

Passing parameters to AntRunner from command line

The build generated by the above command will leave the feature jar inside the feature project and the plug-in jar inside the plug-in project folder. Of course they shouldn't scattered all around. They need to be collected to one place.

Open the build.xml for the plug-in project and inside the 'init' target there is one property called 'plugin.destination'. It is this location where the jar is finally created by the 'build.update.jar' target.

<property name="plugin.destination" value="${basedir}"/>

Change the value of this property to "${buildDirectory}". Make the similar change for the 'feature.destination' property in the build.xml for the feature project.

If the build is triggered now, it will fail because it can not find the value for the 'buildDirectory'. The value can be provided through command line using -D option.

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-workspace-path>\<feature-project-path>\<build-xml-path> -DbuildDirectory=<build-storage-location>

java -jar C:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile C:\workspace\com.example.helloworld.feature\build.xml -DbuildDirectory=c:\build\buildOutput

When the build is run, ${buildDirectory} will be replaced by the value(location) provided and jars will get created there.

More parameters can be supplied using -D<variable-name>=<value> from the command line.

Ant properties file

Passing parameters from the command line is not very scalable or maintainable. A better way is to pass the parameters using a properties file.

Create a properties file, say, '' inside a folder, say, 'buildConfiguration'. The name '' have been chosen to distinguish it from ''. Carefully note that though both are name=value kind properties file, it is common(rather better) practice to not mix them. Since '' has a special meaning in context of PDE, it is recommended that a different name is used to avoid any confusion.

Store the property and its value in the properties file.
Note the forward slashes instead of backslash. The backslashes will work too but needs to be escaped.

Now open the build.xml for the feature project and add the 'loadproperties' entry under the 'project' tag.
<project name="com.example.helloworld.feature" default="build.update.jar" basedir=".">
 <loadproperties srcfile="../../buildConfiguration/" />
This entry needs to be made only in feature project's build.xml and is not required for the plug-in projects' build.xml. They still can use the same variable name and will get the value from the properties file.

Note that the value for the 'srcfile' is a relative path and the ../../ (grand-parent directory) indicates that the properties file has been kept in one folder outside the folder (or workspace) containing the projects.

Monday, June 14, 2010

Headless Build for Beginners - part I

The easiest way to generate the plug-in jars is through Export Wizard. Assuming we already know this, lets try to play with headless build.

Headless Build
Here the workbench (IDE or UI) is referred to as 'head'. Headless build essentially means running the builds from command line in non-UI mode. This can be achieved by various means, however, we will start with java command line and org.eclipse.equinox.launcher jar.

Java -jar
This is standard Java part. Java executable has many command line options and -jar is one of them. The curious souls can learn more about packaging and executing jars. 

Eclipse has its own OSGi implementation which is known as Equinox. 'org.eclipse.equinox.launcher' is a plug-in as well as executable jar that launches the OSGi Runtime. It is located under plug-ins folder as org.eclipse.equinox.launcher_<version><qualifier.jar> ( for example org.eclipse.equinox.launcher_1.1.0.v20100507.jar).
This '-application' option tells 'org.eclipse.equinox.launcher' that which application has to be launched. The application is identified by its id. The application is discovered using the Application Admin service. The Runtime Application Model explains how it works.

Its the application id for the AntRunner application. It is contributed by org.eclipse.ant.core plug-in and its purpose it to run Ant build files.

Its the Ant script to build the plug-in. Good news is the we need not be expert in Ant (however it good to have some knowledge about it). The PDE Build can generate this help for us. Right click on the and select PDE Tools -&gt; Create Ant Build File. This will generate build.xml and javaCompiler...args files. There may be more and specially name of the later may vary depending on the output. entry in the file.

Putting the pieces together
Assuming that the name of the plugins project is 'com.example.helloworld' the command to build it headlessly will be

java -jar <eclipse-installation-path>\plugins\org.eclipse.equinox.launcher_<version><qualifier>.jar -application org.eclipse.ant.core.antRunner -buildfile <eclipse-workspace-path>\<project-name>\<build-xml-path>

java -jar C:\eclipse\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.ant.core.antRunner -buildfile C:\workspace\com.example.helloworld\build.xml

This will build the plug-in project according to build.xml script. Since it was generated for us from build.propertied, it is essentially this file that governs the build. Note that build.xml is not generated automatically not kept in sync with For any modifications to be reflected, the build.xml file has to be regenerated.
Assuming our plug-in does not have the Bundle-Classpath entry in the Manifest.MF file and source.. and output.. are the only source and output entries in our The resultant build of such a plug-in will be in a folder '@Dot' in the project along with the log-file @dot.log .
This is not quite we expected. We were hoping to see a com.example.helloworld_1.0.0.v201006141121.jar kind of file. This happened because the default target (task) will just compile the classes. To make it generate the jar, edit build.xml and make the default target 'build.update.jar' (mentioned in the very first line).

<project name="com.example.helloworld" default="build.update.jar" basedir=".">

This shall generate the com.example.helloworld_<version><qualifier>.jar in the project folder. The build.xml can be modified to have it created in a desired location instead. Also note that the timestamp that replaces 'qualifier' is not the build time but the time when the build.xml was generated.