Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Platform Plug-in Development Environment Guide
Previous Page Home Next Page

Feature and Plug-in Build Configuration Properties

The build mechanism is driven by a build configuration.  The build configuration for an individual plug-in, fragment, or feature is found in a build.properties file for the corresponding element.

PDE project creation wizards generate the build.properties file when plug-in projects are created. The file contains information on how to compile source folders into JARs. This information can be indirectly updated in the Runtime page of the manifest editor. It can also be directly modified using the appropriate editor.

PDE provides a simple editor for the build.properties that has form and source views. The file itself follows the Java properties format. You need to provide a number of keys and their corresponding values. Multiple values are separated using a comma as the delimiter.

Common properties

  • bin.includes - lists files that will included in the binary version of the plug-in being built;
  • bin.excludes - lists files to exclude from the binary build;
  • qualifier - when the element version number ends with .qualifier this indicates by which value ".qualifier" must be replaced. The value of the property can either be context, <value> or none. Context will generate a date according to the system date, or use the CVS tags when the built is automated. Value is an actual value. None will remove ".qualifier". If the property is omitted, context is used. (See Version Qualifiers.)
  • custom=true - indicates that the build script is hand-crafted as opposed to automatically generated. Therefore no other value is consulted.
  • customBuildCallbacks - indicates an xml file containing custom targets to use when using this feature/plug-in.  (See Featureand Plug-in Custom Build Steps)
  • customBuildCallbacks.failonerror - sets the subant task's failonerror parameter. The default is "false".
  • customBuildCallbacks.buildpath - sets the subant task's buildpath parameter. Use when the location of the custom callbacks file is not relative to the root of the plug-in.
  • customBuildCallbacks.inheritall - sets the subant task's inheritall parameter. Ant's default is false.

Plug-in specific properties

  • source.<library> - lists source folders that will be compiled (e.g. source.xyz.jar=src/, src-ant/). If the library is specified in your plug-in.xml or manifest.mf, the value should match it;
  • output.<library> - lists the output folder receiving the result of the compilation;
  • exclude.<library> - lists the files that should not be copied into the library by the compiler;
  • extra.<library> - extra classpaths used to perform automated build. Classpath can either be relative paths, or platform urls referring to plug-ins and fragments of your development environment (e.g. ../someplugin/xyz.jar, platform:/plugins/org.apache.ant/ant.jar). Platform urls are recommended over relative paths;
  • manifest.<library> - indicate the file that will be used as a manifest for the library. The file must be located in one of the source folder being used as input of the jar.
  • src.includes - lists files to include in the source build;
  • src.excludes - lists files to exclude from the source build;
  • jars.extra.classpath - (deprecated) same effect than extra.<library> except that the entries are applied to all libraries;
  • jars.compile.order - defines the order in which jars should be compiled (in case there are multiple libraries).
  • jre.compilation.profile - set the Environment used to compile this bundle.  (See Controlling the Compilation Environment)
  • javacSource - set the source compatibility level for compiling this bundle.  Overrides jre.compilation.profile.
  • javacTarget - set the target .class compatibility level for compiling this bundle.  Overrides jre.compilation.profile.
  • bootClasspath - set the boot classpath to compile this bundle against, Overrides jre.compilation.profile.
  • javacWarnings.<library> - set the warning options to pass to the compiler.  (See the -warn option in Compiling Java Code from the JDT Plug-in Developer Guide).
  • javacDefaultEncoding.<library> - sets default encoding to use when compiling the given library.
  • javacCustomEncodings.<library> - a comma separated list of paths and encodings to use when compiling the given library.  Example:
    javacCustomEncodings.library.jar = src/org/foo[US-ASCII], src/org/foo/bar.java[ISO-8859-1]

The values defined for these keys ending with "includes" or "excludes" are expressed as Ant "patterns". Standard formats give the expected results.  For example, "*.jar" indicates all jar files in the top level directory. The patterns are not deep by default.  If you want to describe all Java files for example, you should use the pattern "**/*.java".   The pattern "**" matches any number of directory levels.  Similarly, to describe whole sub-trees, use "xyz/".

Feature specific properties

  • root - List the files and folders that must be included in the root of the product. See the Rootfiles help page for more detail, incuding the following additional properties:
    • root.<config>: per configuration rootfiles.
    • root.folder : rootfiles placed in subfolders.
    • root.permissions : perform chmods on rootfiles.
    • root.link : generate softlinks for rootfiles.
  • root.<config> - list the files and folders that must be included in the root of the product when it is built for the specified configuration. config is composed of the three (3) segments of a configuration separated with a dot;
  • root.permissions.<permissionValue> - list the files and folders to chmod to the given value. Reference to folders must ends with a '/';
  • root.permissions.<config>.<permissionValue> - list the files and folders to chmod to the given value for a specific configuration. Reference to folders must ends with '/';
  • root.link - list by pairs (separated by a comma) the files and folders that need to be symbolicly linked. The first entry indicate the source (target in the unix terminology) and the second entry the link name;
  • root.link.<config> - a comma separated list of pairs of files and folders that need to be symbolicly linked for a specific configuration. The first entry indicate the source (target in the unix terminology) and the second entry the link name;
  • [email protected]<featureId> - indicates that the source feature featureId will be the source feature for the feature indicated as value of this property. The values listed after the first comma indicates elements to be fetched from the repository;  (See SourcePlugin and Feature Generation)
  • [email protected]<pluginId> - indicates that the source plug-in pluginId will be the source plug-in for the indicated as value of this property.
  • significantVersionDigits - The number of significant digits used when generating feature version suffixes  (See VersionQualifiers)
  • generatedVersionLength - The length of the generated feature version suffix.
The following example has been extracted from the build.properties of the org.eclipse.platform feature.
bin.includes=epl-v10.html,eclipse_update_120.jpg,feature.xml,feature.properties,license.html

root=rootfiles,configuration/
root.permissions.755=eclipse

root.linux.motif.x86=../../plugins/platform-launcher/bin/linux/motif,linux.motif
root.linux.motif.x86.link=libXm.so.2.1,libXm.so.2,libXm.so.2.1,libXm.so
root.linux.motif.x86.permissions.755=*.so*


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire