Generating Ant scripts from the command line

Ant scripts are typically generated using the Plug-in Development Environment (PDE), but it is also possible to generate them by hand or from other scripts.
Indeed PDE exposes Ant tasks to generate the various build scripts. Build script generation facilities reside in the following tasks. Arguments are also listed for each task.

eclipse.fetch: generates an Ant script that fetches content from a CVS repository. The eclipse fetch is driven by a file whose format is described below (see Directory file format).

elements:	the entry that will be fetched. The format expected is of the form type@id[,version] as specified in the directory file format;
buildDirectory:	the directory into which fetch scripts will be generated and into which features and plug-in projects will be checked out;
directory:	the path to a directory file;
children:	optional, specifies whether the script generation for contained plug-ins and fragments should be invoked. Default is set to true;
cvspassfile:	optional, the name of a CVS password file;
fetchTag:	optional, overrides the tag provided in directory file by the given value;
configInfo:	optional, an ampersand separated list of configuration indicating the targeted configuration. The default is set to be platform independent;
recursiveGeneration:	optional, specify whether or not fetch scripts should be generated for nested features. The default is set to true.

eclipse.buildScript: generates a build.xml file for the given elements as well as additional scripts used by the pde build infrastructure.

elements :	the entry to be built. Entry is expected to be of the form type@id[,version] as specified in the directory file format;
buildDirectory :	the directory where the features and plug-ins to build are located. Plug-ins and features must respectively be located in `plugins` and `features` folders;
children :	optional, specifies whether the script generation for contained plug-ins and fragments should be invoked. Default is set to true;
recursiveGeneration :	optional, specified whether the script generation for contained features should be invoked. Default is set to true;
devEntries :	optional, a comma separated list of directories to be given to the compile classpath;
buildingOSGi :	optional, indicates if the target is 3.x. or 2.1. Default is true;
baseLocation :	optional, indicates a folder which containing a target eclipse install with `features/` and `plugins/` subdirectories;
configInfo :	optional, an ampersand separated list of configuration indicates the targeted configuration. The default is set to be platform independent;
pluginPath :	optional, a platform file separator separated list of locations from which to find additional plug-ins;
archivesFormat :	optional, an ampersand separated list of configs and the expected output format for each of those. The format is separated by a dash (-) from the configuration. The values supported are: folder, tar, zip, antZip, respectively meaning don't archive, use tar to create the archive, use the version of info zip available on the platform, use ant zip . The default value is antZip;
product :	optional, '/' separated path to the location of an RCP product being built. The first segment of the path must refer to the plug-in id of a plug-in containing the .product file;
signJars :	optional, indicates if the scripts generated must sign jars for features and plug-ins. The default value is false. The parameters to the sign task are controlled by the following ant properties: sign.alias, sign.keystore and sign.storepass respectively being passed to the alias, keystore and storepass parameters from the ant signJar task. The default value is false;
generateJnlp :	optional, indicates if a jnlp file should be generated for all the features being built;
outputUpdateJars :	optional, generates plug-ins and features in the update site format when set. The default value is false. Note that the site.xml is not generated nor updated;
groupConfiguration :	optional, whether or not to group all configurations being built into a single archive;
generateVersionsLists :	optional, whether or not to generate properties files listing the versions of features and plug-ins that were built;
filteredDependencyCheck :	optional, constrain the set of plug-ins and features to be considered during the build to those reachable from the features;
filterP2Base :	optional, constrain the set of plug-ins and features to be considered from the baseLocation to those considered to be installed by p2;
generateFeatureVersionSuffix:	optional, whether or not to generate the feature version suffix. See also Version Qualifiers;
generatedVersionLength :	optional, the length of the generated feature version suffix. By default it is set to 28. See also Version Qualifiers;
significantVersionDigits :	optional, the number of significant digits used when generating feature version suffixes. See also Version Qualifiers;
forceContextQualifier :	optional, uses the given value to replace the .qualifier being by plug-ins and features. See also Version Qualifiers;

eclipse.generateFeature: generates a feature that will contain the provided elements. This task is used to build an RCP application from a product configuration file.

featureId :	The id to give to the generated Feature.
buildDirectory:	the directory where the features and plug-ins (in `/features` and `/plugins` subdirectories) to include are located. The generated feature will be placed in the /features subdirectory.
baseLocation :	optional, indicates a folder which contains installed features and plug-ins
productFile :	optional, a product file on which to base the generated feature.
verify :	Whether or not to use the resolver to verify that the provided plug-ins and features are available. This also determines whether or not the the feature will be able to correctly handle platform specific fragments and plug-ins that will be JARed. If all the elements to be included in the feature are available locally, then verify should be set to True. If the elements need to be fetched from a repository, set verify to False, use the resulting feature to fetch the required plug-ins and features, then regenerate the container feature using verify = True.
pluginPath :	optional, a platform file separator separated list of locations from which to find additional plug-ins
configInfo :	optional, an ampersand separated list of configuration indicates the targeted configuration. The default is set to be platform independent;
pluginList :	optional, a comma separated list of plug-in ids to include in the generated feature. (Supports attributes, see below)
featureList :	optional, a comma separated list of feature ids to include in the generated feature. (Supports attributes, see below)
fragmentList :	optional, a comma separated list of fragment ids to include in the generated feature. (Supports attributes, see below)
buildPropertiesFile :	optional, the location of a properties file whose contents should be used as the generated feature's build.properties.
includeLaunchers :	optional, whether or not to include the equinox launchers, default value is "true".

The pluginList, featureList, and fragmentList arguments of the eclipse.generateFeature task all support attributes. These arguments all take the form:

List = <element-id>[;<attribute>=<value>]* [,<element-id>[;<attribute>=<value>]*]*

Each attribute=value pair will be inserted into the generated xml corresponding to the given element. Example:

    	featureList = org.eclipse.feature;optional=true
    	pluginList = org.eclipse.plugin.A;unpack=true
    	fragmentList=org.eclipse.fragment.a;os=win32,org.eclipse.fragment.b;os=linux;ws=gtk;arch=x86
    	
    	<feature ...>
    	     ...
    	     <includes id="org.eclipse.feature" version="0.0.0" optional="true" />
    	     ...
    	     <plugin id="org.eclipse.plugin.A" version="0.0.0" unpack="true" />
    	     <plugin id="org.eclipse.fragment.a" version="0.0.0" os="win32" fragment="true" />
    	     <plugin id="org.eclipse.fragment.b" version="0.0.0" os="linux" ws="gtk" arch="x86" fragment="true" />
    	     ...
    	</feature>

Examples

<eclipse.fetch elements="bundle@org.eclipse.osgi"
		buildDirectory="c:\toBuild"
		directory="directory.txt"
		configInfo="win32,win32,x86 & linux, motif, x86"
		/>
		
<eclipse.buildScript elements="bundle@org.eclipse.osgi" 
		buildDirectory="c:\toBuild"
		archivesFormat="macosx, carbon, ppc - tar"/>

Directory file format

Directory files are used to indicate where the plug-ins and features can be obtained, as well as their versions. It is a Java property file whose keys are always of the form type@id[,version] but where the value is open ended. When using map files to fetch your elements, the directory file is a concatenation of all the map files, for more details on map files see Fetching From Repositories.

Using the targets

The tasks previously described only work if Eclipse is running. In the particular scenario of executing Ant scripts using Eclipse tasks,the scripts must be run using the Eclipse Ant Runner application. The command line for this particular case is the following:

  java -jar plugins/org.eclipse.equinox.launcher_<version>.jar -application org.eclipse.ant.core.antRunner -buildfile build.xml

Note that the parameters appearing after the application are the parameters that are passed to Ant.