The <build> Section

• Related Topics:
• Resource Assembling
• Customization
• Localization
• Preprocessing

Control your build process with the <build> section!

The <build> section is the main configuration point of J2ME Polish.

<build
     fullscreen="menu"
     usePolishGui="true"
     >
     <!-- midlets definition -->
     <midlet class="de.enough.polish.example.MenuMidlet" name="Example" />
     <!-- project-wide variables - used for preprocessing  -->
     <variables>
       <variable file="configs/all.properties" />
       <variable file="configs/${polish.vendor}.properties" />
     </variables>
     <!-- obfuscator settings -->
     <obfuscator name="ProGuard" unless="test or polish.blackberry"  />
     <!-- debug settings -->
     <debug showLogOnError="true" 
               verbose="true" 
               level="error"
	       if="test" 
	       >
        <filter package="de.enough.polish.example" level="debug" />
        <filter class="de.enough.polish.ui.Gauge" level="info" />
     </debug>
</build>

Supported Attributes

The build section has... well... some options that you can use. Thankfully most of the settings are optional. For a good starting point have a look at the build.xml scripts of the sample applications.

<build
	usePolishGui="true"
	fullscreen="menu"
>
  <variables>
     <variable 
	name="polish.FullScreen" 
	value="true"
	if="polish.vendor == Siemens"
     />
  <variables>
    [...]

Nested Elements

The build section supports very few nested elements that are described below in detail.

<sources>

The <sources> element can be used for a finer grained control of the source-directories. This can be useful to include test classes, for example:

<sources>
	<source dir="source/src" />
	<source dir="source/test" if="test" />
</sources>

<libraries>

Add compiled libraries to your project with the <libraries> element:

<libraries>
	<library file="libraries/tinyline.gz" />
	<library file="libraries/svghelper.jar" if="polish.api.svg" />
</libraries>

<midlet> and <midlets>

The <midlet> element defines the actual MIDlet class:
<midlet class="de.enough.polish.example.ExampleMidlet" />

The optional <midlets> element is used as a container for several <midlet> elements and also supports the if/unless attributes:

<midlets>
	<midlet class="de.enough.polish.example.ExampleMidlet" />
	<midlet name="J2ME Polish Demo" number="2" icon="no2.png"
		  class="de.enough.polish.example.GuiDemoMidlet" />
</midlets>

<iappli>

The <iappli> or <doja> element defines the IApplication class of your DoJa release. This is only applicable when you are targeting this platform.

<resources>

<resources
	dir="resources"
	excludes="*.txt"
>
	<fileset 
		dir="resources/multimedia" 
		includes="*.mp3" 
		if="polish.audio.mp3" 
	/>
	<fileset 
		dir="resources/multimedia" 
		includes="*.mid" 
		if="polish.audio.midi and not polish.audio.mp3" 
	/>
	<fileset 
		dir="resources/multimedia/${polish.language}" 
		includes="*.mid" 
	/>
	<localization locales="de, en" unless="test" />
	<localization locales="en" if="test" />
</resources>

The <resources> element can be used to fine tune the resources assembling as well as the localization of the application. When it is used, the "resDir"-attribute of the <build> section should not be used. The <resources> element supports following attributes:

The <resources> elements accepts the nested elements <root>, <localization> <filter>, <fileset> and <copier>.

The <root> Subelement

By default you only have the single root directory resources in your project. You can, however, define as many roots and even conditional roots using the <root> element:

<resources
	dir="resources/base"
	defaultexcludes="true"
	excludes="readme.txt"
>
	<root dir="resources/base/design" />
	<root dir="resources/base/sounds" />
	<root dir="resources/base/images" />
	<root dir="resources/base/images/largescreens" 
		if="polish.ScreenWidth &gt;= 240 and polish.ScreenHeight &gt;= 300" 
	/>
	<root dir="resources/base/images/i18n" 
		includeSubDirs="true" includeBaseDir="true" excludes="CVS, readme*" 
	/>
</resources>

resources/base/images/i18n/en/flag.png
resources/base/images/i18n/de/flag.png
resources/base/images/i18n/dk/flag.png
resources/base/images/i18n/fr/flag.png
resources/base/images/i18n/es/flag.png
resources/base/images/i18n/cn/flag.png

The <localization> Subelement

Control the internationalization of your application with the the <localization> element:

<localization dynamic="true" defaultLocale="en">
	<locale name="en" encoding="UTF-8" />
	<locale name="de" encoding="UTF-8" />
	<locale name="cn" encoding="GB2312" />
</localization>

Use Locale Dependent Encodings with <locale>

Use nested <locale> elements for configuring settings for each locale that you support:

<locale name="cn" encoding="GB2312" if="polish.vendor == Motorola" />

The <filter> Subelement

Sometimes it is easier to exclude resources for specific devices rather than to include it for the other devices. You can use any number of <filter> elements for this purpose. The following element removes all *.mid files when the target device supports both MIDI as well as AMR files:

<filter excludes="*.mid" if="polish.audio.midi and polish.audio.amr" />

The <fileset> Subelement

You can use <fileset> for fine tuning the resource assembling. Nowadays we recommend using <root> instead.
The <fileset> behaves like any Ant fileset, but it offers the additional "if" and "unless"-attributes for allowing a fine grained control. The most important attributes are:

<resources
	dir="resources"
	excludes="readme*" 
>
	<fileset 
		dir="resources/multimedia" 
		includes="*.mp3" 
		if="polish.audio.mp3" 
	/>
	<fileset 
		dir="resources/multimedia" 
		includes="*.mid" 
		if="polish.audio.midi and not polish.audio.mp3" 
	/>
</resources>

In the above example MIDI files are only included when two conditions are met:
1) The device supports MIDI sound
2) The device does not support MP3 sound.

The <copier> Subelement

Use the <copier> element to transform the resources before they are packaged in the final JAR file. You can chain several copiers together just by defining several <copier> elements.

The antcall Resource Copier

The "antcall" resource copier executes another target in your build.xml script for copying the resources. You can use all (lowercase) J2ME Polish variables and properties of the current target device as well as following specific properties:

• ${polish.resources.target}: contains the target directory, to which the resources need to be copied
• ${polish.resources.files}: includes a comma separated list of the files that should be copied
• ${polish.resources.filePaths}: includes a semicolon (Windows) or colon (Unix) separated list of the files that should be copied.

You can also specify your own properties by using nested <parameter> elements.

<copier name="antcall" target="copyresources">
	<parameter name="MySettings" value="${polish.name}.settings" />
</copier>

The renamer Resource Copier

Use the "renamer" resource copier for modifying the file-names of the resources before they are packaged in the final JAR. The following renamer removes all characters that are surrounded by curly braces. You can use this for giving your resources meaningful names while using short names in the JAR file. The file i0{ start game icon }.png will be renamed to i0.png, for example. This saves some precious space.

<copier name="renamer">
	<!-- use a regular expression for defining
           name parts that should be changed: 
	-->
	<parameter name="searchPattern" value="\{.*\}" />
	<!-- define the replacement for the searchPattern here: -->
	<parameter name="replacement" value="" />
</copier>

The svgconverter Resource Copier

Use the "svgconverter" for modifying SVG images of the resources before they are packaged in the final JAR. The svgconverter allows you to provide only one icon or background image for a variety of phones. It scales the SVG image to the appropriate size of the current target device and converts it into a PNG image. For an background image you have to start naming your image "bg"("bg"+whatever+".svg"), for an icon start with "icon". The svgconverter then uses the defined ScreenSize and IconSize of the target device for scaling such images. When the target device does not specify these sizes the default size for icons is 15x15 and for backgrounds 128x160 pixels.

<copier name="svgconverter" />

<compiler>

The optional <compiler> element can be used for specifying any compiler-arguments. J2ME Polish normally calls the Java compiler normally with the appropriate classpath as well as bootclasspath for the current target device. In some cases you might want to adjust the compiler settings, however, so you can use the nested <compiler> element. Along to all attributes of the standard <javac> task, the <compiler> element also supports the "if" and "unless" attributes for selecting to appropriate compiler setting:

The <compilerargs> Subelement

You can specify additional command line arguments for the compiler with nested <compilerarg> elements. These elements are specified like Command-line Arguments but have an additional attribute that can be used to enable arguments only if a given compiler implementation will be used.

<postcompiler>

Use a <postcompiler> for adjusting the class files after they have been compiled.

Prime example of the power of postcompiling are the Java 5 Syntax Support and the Floater Tool, which allows you to use floating point calculations on CLDC 1.0 devices.

<postcompiler name="java5" />

You can also call an Ant target in your build.xml script for post-processing class files:

<postcompiler name="antcall" target="AntPostcompileTarget" />

Next to all device capabilities you can access the polish.postcompile.dir Ant property in your target.

<obfuscator>

The optional <obfuscator> element controls the obfuscating of the application bundle, which decreases the jar-size and makes it difficult to reverse engineer the application.

<obfuscator name="ProGuard" useDefaultPackage="true" unless="test" />

Any number of <obfuscator> elements can be used in a project. All active obfuscators are combined by J2ME Polish.

The <obfuscator> supports the subelements <keep> and <parameter>.

The <keep> Subelement

The <keep> element is used to define classes which are loaded dynamically (e.g. with Class.forName(...) ) and should not be obfuscated:

<obfuscator unless="test" enable="true" name="ProGuard" >
	<keep class="com.company.dynamic.SomeDynamicClass" />
	<keep class="com.company.dynamic.AnotherDynamicClass" />
</obfuscator>

The used MIDlet classes do not need to be set with the <keep> element, since they are saved from obfuscation automatically.

The <parameter> Subelement

The <parameter> element is used to specify parameters for the obfuscator. This can be useful for integrating third party obfuscators which require additional settings:

<obfuscator unless="test" enable="true" name="ProGuard" >
	<keep class="com.company.dynamic.SomeDynamicClass" />
	<keep class="com.company.dynamic.AnotherDynamicClass" />
	<parameter name="scriptFile" value="../scripts/obfuscate.script" />
</obfuscator>

Combining Several Obfuscators

Several obfuscators can be combined just by specifying several <obfuscator> elements. When the <keep> subelement is used, it only needs to be specified on of the <obfuscator> elements. J2ME Polish will then use the obfuscated output of one obfuscator as input for the following obfuscator.

Specific Obfuscator Settings

ProGuard

ProGuard is an excellent obfuscator, shrinker and optimizer by Eric Lafortune. It is freely availabe under the GNU General Public License and can be downloaded from http://proguard.sourceforge.net.

If you want to use ProGuard as an obfuscator, please make sure that the proguard.jar-file is listed in the classpath of the J2ME Polish task-definition (build.xml):

<taskdef name="j2mepolish" 
	classname="de.enough.polish.ant.PolishTask" 
	classpath="${polish.home}/import/enough-j2mepolish-build.jar:
		${polish.home}/import/jdom.jar:
		${polish.home}/import/proguard.jar"/>

You can use ProGuard by setting the name-attribute of the <obfuscator> element to "ProGuard".

ProGuard 3.x offers an additional optimization of the bytecode, which is disabled by default. The optimization can be enabled by setting the "optimize"-parameter to "true":

<obfuscator unless="test" enable="true" name="ProGuard" >
	<parameter name="optimize" value="true" />
</obfuscator>

A text-file which lists all renaming operations is written to build/[vendor]/[device]/[locale]/obfuscation-map.txt. This file is useful if you get exceptions in the obfuscated application.

yGuard

The yGuard obfuscator by the yWorks GmbH is another interesting obfuscator and code-shrinker. J2ME Polish includes the library-classes, which are licensed under the GNU Lesser General Public License. The full obfuscator is freely available from http://www.yworks.de.

If you want to use yGuard as an obfuscator, please make sure that either the yguard-lib.jar or the original yguard.jar is listed in the classpath of the J2ME Polish task-definition (build.xml):

<taskdef name="j2mepolish" 
	classname="de.enough.polish.ant.PolishTask" 
	classpath="${polish.home}/import/enough-j2mepolish-build.jar:
		${polish.home}/import/jdom.jar:
		${polish.home}/import/yguard-lib.jar"/>

The yGuard obfuscator can be used by setting the name-attribute of the <obfuscator> element to "YGuard":

<obfuscator unless="test" enable="true" name="YGuard" />

RetroGuard

RetroGuard is the basis of both yGuard and ProGuard and was developed by Retrologic Systems/Mark Welsh. It is licensed under the GNU Lesser General Public License and is included in J2ME Polish by default. It can be downloaded from http://www.retrologic.com.

You can use RetroGuard just by setting the "name"-attribute to "RetroGuard":

<obfuscator unless="test" enable="true" name="RetroGuard" />

Zelix KlassMaster

KlassMaster is a commercial obfuscator available from Zelix Pty Ltd. A free evaluation version can be requested at http://www.zelix.com.

The KlassMaster integration is based on the WTK-mechanism for calling obfuscators, therefore both the ZKM.jar as well as the kenv.zip needs to be on the classpath:

<taskdef name="j2mepolish" 
	classname="de.enough.polish.ant.PolishTask" 
	classpath="${polish.home}/import/enough-j2mepolish-build.jar:
		${polish.home}/import/jdom.jar:
		${polish.home}/import/ZKM.jar:${wtk.home}/wtklib/kenv.zip"/>

The KlassMaster-integration allows several parameters to be set:

• enableFlowObfuscation: the flow-obfuscation increases the security of the application, but the application-size as well. It is deactivated by default, therefore. It can be activated by setting the enableFlowObfuscation-parameter to "true".
• ObfuscateFlowLevel: The obfuscation-flow level can also be set directly, e.g. "none" or "aggressive". This parameter takes precedent above the enableFlowObfuscation-parameter.
• ScriptFile: The file containing the full script can also be set. In that case please note that the source-jar-file is always the "build/source.jar" and the target-file is the "build/dest.jar".

The following example shows a possible invocation of KlassMaster:

<obfuscator unless="test" enable="true" name="KlassMaster" >
	<parameter name="ObfuscateFlowLevel" value="none" />
</obfuscator>

DashO Pro

DashO Pro is a commercial obfuscator by Preemptive Solutions. A free evaluation version can be requested at http://www.preemptive.com.

When the DashO Pro obfuscator is used, either the Ant property "dasho.home" or the parameter "DashoHome" needs to be given. The classpath does not need to be modified.

The DashO Pro obfuscator supports following parameters:

• DashoHome: needs to point to the installation directory of the DashO Pro obfuscator.
• Version: needs to correspond to the used version of DashO. The current default version is "3.1".
• enableFlowObfuscation: when "true" is given, DashO will obfuscate the application flow as well. This is deactivated by default.
• enableStringEncription: when "true" is given, Strings will be obfuscated by DashO as well. Since this decreases the performance, it is deactivated by default.
• enableRenaming: when "true" is given, all possible classes will be renamed. This is activated by default.
• enableOptimization: when "true" is given, the byte-code will be optimized by DashO. This feature is activated by default.
• ConstantPoolTag: a tag which will be added to all processed classes. This is only visible when a decompiler is used.
• ScriptFile: The file containing the full script can also be set. In that case please note that the source-jar-file is always the "build/source.jar" and the target-file is the "build/dest.jar".

A report about the renamed clases as well as methods will be written to build/[vendor]/[device]/[locale]/obfuscation-map.txt. This file is useful for resolving stacktraces in the obfuscated application.

This example shows the integration of DashO Pro:

<obfuscator unless="test" enable="true" name="Dasho" >
	<parameter name="DashoHome" value="/home/user/DashOPro_3.1" />
	<parameter name="Version" value="3.1" />
</obfuscator>

JODE

JODE is quite a powerful optimizer, shrinker and obfuscator by Jochen Hoenicke. It is licensed under the GNU General Public License and is available at http://jode.sourceforge.net free of charge.

If you want to use JODE, please make sure that the jode-jar-file is on the classpath:

<taskdef name="j2mepolish" 
	classname="de.enough.polish.ant.PolishTask" 
	classpath="${polish.home}/import/enough-j2mepolish-build.jar:
		${polish.home}/import/jdom.jar:
		${polish.home}/import/Jode-1.1.2-pre1.jar"/>

JODE supports the "ScriptFile"-parameter which can be used to specify the obfuscator-script. Please note that the source-jar-file is always the "build/source.jar" and the target-file is the "build/dest.jar":

<obfuscator unless="test" enable="true" name="Jode" >
	<parameter name="ScriptFile" value="obfuscate.jos" />
</obfuscator>

When no script-file-parameter is present, J2ME Polish will create a default script. Depending on the application and environment, several problems ranging from preverification/linking-errors to NullPointerExceptions in the JODE-API can occur. Maybe someone with more experience with JODE can provide help here - please get in touch with j2mepolish@enough.de.

<variables>

The optional <variables> element contains several variable definitions, which can be used for the preprocessing. This mechanism can be used for example to define configuration values:

<variables includeAntProperties="true">
	<variable name="update-url" value="http://www.enough.de/update" />
	<variable name="polish.TiledLayer.splitImage"
		     value="true" 
		     if="polish.Vendor == Nokia" />

</variables>

The <variables> element contains an arbitrary number of <variable> elements, which define the actual variables. Each variable needs the attributes name and value:

Variables which have been defined in this way can be included into the source code with the "//#=" preprocessing directive and can be checked with the "[variable-name]:defined" symbol:

//#ifdef update-url:defined
	//#= String url = "${ update-url }";
//#else
	String url = "http://www.default.com/update";
//#endif

Variables can also be compared, please refer to the description of the #if-directive for more information.

<debug>

The optional <debug> element controls the inclusion of debugging messages for specific classes or packages. The debugging messages will be activated or deactivated in the source code, so the performance will not be decreased, when the debugging is deactivated.

<debug showLogOnError="true" verbose="false" level="error" if="test" >
	<filter pattern="com.company.package.*" level="info" />
	<filter pattern="com.company.package.MyClass" level="debug" />
</debug>

In the source code any debug messages must be accompanied by a //#debug-directive:

//#debug
System.out.println("initialization done.");
or
//#debug warn
System.out.println("could not load something...");
or
//#debug error
System.out.println("could not load something: " + e);

You will find more information about the debugging possibilities in the introduction as well as in the preprocessing documentation.

//#debug error
System.out.println("could not load something: " + e);

For a finer control of the debugging process, the <debug> element allows the sub-element <filter>, which defines the debug-level for specific classes or packages.

<jad>

With the <jad> element user-defined attributes can be added to the JAD-file (Java Application Descriptor) as well as the MANIFEST-file which is contained in the created JAR-file. The element contains a number of -sub-elements which define the actual attributes:

<jad>
 <attribute 	name="Nokia-MIDlet-Category" 
 		value="Game" 
		if="polish.group.Series40" />
 <attribute 	name="MIDlet-Push-1" 
 		value="socket://:79, com.sun.example.SampleChat, *" 
		if="polish.midp2" />
</jad>	

Attributes which are defined in this way can be loaded in the application with the MIDlet.getAppProperty( String name ) method, which needs the name of the attribute as an argument and returns the value of that argument. Often it is advisable to use the variable-mechanism of J2ME Polish instead, since such values are actually hard-coded into the application and are, therefore, much faster than the getAppProperty(...)-mechanism.

Sorting and Filtering JAD attributes

The JAD-attributes can filtered and sorted using the <jadFilter> subelement:

<jad>
 <attribute 
	name="Nokia-MIDlet-Category" 
	value="Game" 
	if="polish.group.Series40" 
	/>
 <jadFilter>
	MIDlet-Name, MIDlet-Version, 
	MIDlet-Vendor, MIDlet-Jar-URL, MIDlet-Jar-Size, 
	MIDlet-Description?, MIDlet-Icon?, MIDlet-Info-URL?,
	MIDlet-Data-Size?, MIDlet-*, *
 </filter>
</jad>

The <jadfilter> element contains all allowed attribute names in the desired order and separated by commas. You can use different filters by using the "if" or "unless" attributes:

Inside of the <jadfilter> element you can specify all allowed JAD-attributes in the desired order and separated by commas. Following syntax is used:

An overview about allowed attributes can be found at the appendix of the Pro J2ME Polish book.

<manifestFilter>

The manifest filter element can be used to sort and filter manifest attributes. Please note that the first included attribute should always be the "Manifest-Version"-attribute. Otherwise the application will most likely not work:

<manifestFilter>
	Manifest-Version, MIDlet-Name, MIDlet-Version, MIDlet-Vendor,
	MIDlet-1, MIDlet-2?, MIDlet-3?, MIDlet-4?, MIDlet-5?, 
	MicroEdition-Profile, MicroEdition-Configuration,
	MIDlet-Description?, MIDlet-Icon?, MIDlet-Info-URL?,
	MIDlet-Data-Size?
</manifestFilter>

The <manifestFilter> element contains all allowed attribute names in the desired order and separated by commas. You can use different filters by using the "if" or "unless" attributes:

Inside of the <manifestFilter > element you can specify all allowed MANIFEST-attributes in the desired order and separated by commas. Following syntax is used:

An overview about allowed attributes can be found at the appendix of the Pro J2ME Polish book.

<preprocessor>

The <preprocessor> element can be used to integrate own or third party preprocessors. This can be used for allowing new preprocessing directives for example.

<preprocessor
	class="com.company.preprocess.MyPreprocessor" 	
	classPath="import/preprocessing.jar" 	
	>
 <parameter 
	name="scriptFile" 
	value="../scripts/preprocess.script" 
	/>
</preprocessor>	

The preprocessor can be configured using a number <parameter> subelements. Each <parameter> subelement needs to define the attributes "name" and "value".

<packager>

Usually the efficient internal J2ME Polish packager is used for creating the final application bundles. For using a different packaging-program, the <packager> element can be used:

<packager
	executable="jar"
	arguments="cvfM;;${polish.jarPath};;-C;;${polish.packageDir};;."
/>

A much simpler but equally valid call is this:

<packager name="jar" />

A possible alternative might be the Open Source tool "7-Zip", which can create smaller files compared to the standard ZIP mechanism. This might result in problems on the actual device, though, so use with care. The 7-Zip tool can be obtained free of charge at http://www.7-zip.org.

The <packager> element supports following attributes:

<sign>

The <sign> element signs your application for all MIDP 2.0 devices. Please note that you need a valid certificate for example from Verisign or Thawte. Some devices do not contain "open" certificates. In that case you either need to manually install a root certificate (only possible on some devices), use the java verified program or cooperate with a device vendor or an operator.

In the following example we are using the password ant property for specifying the password. In this way it can be specified on the command line without risking the security:

ant -Dpassword=secret

<sign
	key="SignMIDlet"
	keystore="midlets.ks"
	password="${password}"
	unless="test"
/>

<java>

The <java> element can be used to extend J2ME Polish with any Java utility. It accepts all attributes and nested elements like the Ant-<java> element (compare http://ant.apache.org/manual/CoreTasks/java.html) as well as the additional attribute "if", "unless" and "message". J2ME Polish variables can be used in the nested <arg> elements, so that the call can be adjusted for the current device.

Each defined <java> element is called after the successful creation of an application-bundle. A possible use of the <java> element is the signing of MIDlets, which is described in the signing-how-to.

The following example calls the JadUtil.jar of the Wireless Toolkit for signing a JAD file:

<java jar="${wtk.home}/bin/JadTool.jar" 
      	fork="true" 
      	failonerror="true" 
    	if="polish.midp2" 
	unless="test"
	message="Adding signature for device ${polish.identifier}"
	>
	<arg line="-addjarsig"/>
	<arg line="-keypass ${password}"/>
	<arg line="-alias SignMIDlet"/>
	<arg line="-keystore midlets.ks"/>
	<arg line="-inputjad dist/${polish.jadName}"/>
	<arg line="-outputjad dist/${polish.jadName}"/>
	<arg line="-jarfile dist/${polish.jarName}"/>
</java>	

Following variables can be used in the <arg> element and the "message"-attribute:

• polish.vendor: The vendor of the current device, e.g. "Siemens" or "Nokia".
• polish.name: The name of the current device, e.g. "N-Gage".
• polish.identifier: The identifier of the current device, e.g. "Siemens/SX1".
• polish.version: The version of the application as defined in the info-section.
• polish.jarName: The name of the jar-file as defined in the info-section.
• polish.jadName: The name of the jad-file as defined in the info-section.

The most important attributes of the <java> element are:

The most important nested element is the <arg> element:

Please refer to the Ant-documentation at http://ant.apache.org/manual/CoreTasks/java.html for more information about the <java> element.

<finalizer>

After J2ME Polish has finished compiling and packaging your application it can use a finalizer to do some marvelous stuff. This is used for converting a JAR into a COD archieve for BlackBerry devices, for example. An easy way to implement your own functionality is to use the antcall finalizer:

<finalizer name="antcall" target="MyFinalizerAntTarget" />

Next to all capabilities of the current target device you can then access the Ant properties polish.finalize.jar and polish.finalize.jad in your MyFinalizerAntTarget:

<target name="MyFinalizerTarget">
	<echo message="J2ME Polish is now finished with creating ${polish.finalize.jar} and ${polish.finalize.jad} for device ${polish.identifer}" />
</target>