|
|
|
|
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 RCPapplication 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="[email protected]" buildDirectory="c:\toBuild" directory="directory.txt" configInfo="win32,win32,x86 & linux, motif, x86" /> <eclipse.buildScript elements="[email protected]" buildDirectory="c:\toBuild" archivesFormat="macosx, carbon, ppc - tar"/>
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.
|
|
|