root / trunk / install / IzPack / src / doc / CustomActions.tex @ 11445
History | View | Annotate | Download (21.2 KB)
1 | 5819 | cesar | |
---|---|---|---|
2 | % IzPack - Documentation |
||
3 | |||
4 | % Custom actions |
||
5 | |||
6 | \chapter{\label{cha:customactions}Custom Actions} (by Klaus \textsc{Bartz}) |
||
7 | |||
8 | \section{Overview} |
||
9 | |||
10 | In general the installation procedure is separated into several |
||
11 | steps. The first step, let's call it the \emph{data collection phase}, |
||
12 | is getting specific data needed for the installation process. |
||
13 | Typically this is done by typing all neded data into one or more panels, |
||
14 | if a GUI is used, or automatically by reading the data from a config file. |
||
15 | In general nothing will be changed on the system until all needed data is |
||
16 | obtained. But mostly - depending on to the information, e.g. the |
||
17 | destination path - different input panels are involved. |
||
18 | |||
19 | If all needed data is collected the second step will be perfomed, |
||
20 | let us call it the \emph{action phase}. During this step the state of |
||
21 | the locale machine will be changed, e.g. files will be copied to |
||
22 | the installation destination or some short cuts will be registered. |
||
23 | Each of this subsequent steps are denoted as actions. There are actions |
||
24 | intended to be reused, so called common actions, and actions for one special |
||
25 | purpose only, so called custom actions. In IzPack there are already some |
||
26 | common actions, for example "file transfer", "parse" or "execute". |
||
27 | |||
28 | The third step, the \emph{reporting phase}, is normally |
||
29 | represented by a panel that reports the result state of the installation |
||
30 | (OK, or not OK) and a simple good bye message. |
||
31 | |||
32 | With IzPack there are two ways to implement custom actions. Firstly |
||
33 | it is always possible to define a custom panel that perfoms the desired |
||
34 | actions too. Secondly, and that's the new, custom actions are supported. |
||
35 | |||
36 | Panels still may be used for actions that are perfomed, e.g. |
||
37 | before files are transferred or after the "execute" action. |
||
38 | But if the needed action depends on the selected or already installed |
||
39 | packages, this works also, but the implementation effort is much higher. |
||
40 | |||
41 | If the action should be performed for several amount of elements of a |
||
42 | pack, using custom actions will be more easy than using panels. |
||
43 | Additional custom actions may be defined for installation, but also for |
||
44 | packaging and uninstallation purposes. If a custom action is also needed |
||
45 | for uninstallation purposes, it'll be always a good idea to implement a |
||
46 | corresponding installation action as custom action, but not as panel. |
||
47 | |||
48 | \section{How It Works} |
||
49 | |||
50 | Custom actions are implemented as listeners. Each listener implements |
||
51 | callback methods that will be called at well-defined points. The method |
||
52 | \texttt{InstallerListener.afterFile} for example will be called after |
||
53 | a file has been copied. There are different interfaces intended for being |
||
54 | used at packaging time, at installation time and at uninstallation time. |
||
55 | |||
56 | Each interface is implemented by a class with the prefix |
||
57 | "Simple" (e.g. SimpleCompilerListener) that implements all declared interface |
||
58 | methods with an empty body. These classes may be used as base classes |
||
59 | for own listener implementations. |
||
60 | |||
61 | To apply custom actions to the installer, an entry in the apropriate |
||
62 | install.xml file is needed. The configuration of listeners starts with |
||
63 | the facultative ELEMENT "listeners" which can contain one or more ELEMENTs |
||
64 | of "listener". For a "listener" there are three attributes which determine the |
||
65 | "compiler", "installer" and "uninstaller" custom action pupose. |
||
66 | Additionally it is possible to make the listener OS dependent using the "os" |
||
67 | ELEMENT. |
||
68 | |||
69 | If file related data will be set, the facultative ELEMENT |
||
70 | "additionaldata" is defined for the ELEMENTs "file", "singlefile" |
||
71 | and "fileset". This data will be automatically moved to the |
||
72 | corresponding PackFile objects in the install.jar. Extraction and |
||
73 | usage should be implemented in a install custom action (see |
||
74 | example). |
||
75 | |||
76 | |||
77 | |||
78 | |||
79 | \subsection{Custom Action Types} |
||
80 | |||
81 | Custom actions are intended to be used at packaging time, at installation time |
||
82 | and at uninstallation time. The interfaces are: |
||
83 | \begin{center} |
||
84 | \begin{tabular}{|l|l|} |
||
85 | \hline \textit{Custom action type} & \textit{Interface name} \\ |
||
86 | \hline Packaging & com.izforge.izpack.event.CompilerListener \\ |
||
87 | \hline |
||
88 | \hline Installation & com.izforge.izpack.event.InstallerListener \\ |
||
89 | \hline |
||
90 | \hline Uninstallation & com.izforge.izpack.event.UninstallerListener \\ |
||
91 | \hline |
||
92 | \end{tabular}\ |
||
93 | \end{center} |
||
94 | |||
95 | \subsubsection{Custom Actions At Packaging} |
||
96 | |||
97 | \paragraph{UML Diagram} |
||
98 | |||
99 | \begin{center} |
||
100 | \fbox{\includegraphics[scale=1.0]{img/CompilerListener}} |
||
101 | \end{center}\ |
||
102 | |||
103 | \paragraph{Description} |
||
104 | |||
105 | \begin{itemize} |
||
106 | |||
107 | \item \textit{(constructor)} : only the default constructor will |
||
108 | be used. It is called from Compiler just after creating the packager. |
||
109 | Therefore initializing will be better during in the first \texttt{notify} call. |
||
110 | |||
111 | \item \texttt{reviseAdditionalDataMap} gives the facility to add |
||
112 | data to each \texttt{PackFile} object. This is the place where |
||
113 | file related data can be transferred from the install xml file |
||
114 | into the install jar file. Although each key and value of the map can be any |
||
115 | type, but the class definitions of all used types must therfore be contained |
||
116 | in the installer jar file or in the VM's classpath. In general strings |
||
117 | are the best choice for being used as keys or values. All keys must be |
||
118 | unique over all registered \texttt{CompilerListeners}. Each call of this |
||
119 | method adds own key value pairs to the given \texttt{existenDataMap} because |
||
120 | more than one listener can be used. If the given map is null, a |
||
121 | new one will be created. |
||
122 | |||
123 | \item \texttt{notify} is called at the beginning and at the end of each |
||
124 | "add" method call which is called in \texttt{Compiler.executeCompiler}. |
||
125 | |||
126 | \end{itemize}\ |
||
127 | |||
128 | \subsubsection{Custom Actions At Installing Time} |
||
129 | |||
130 | \paragraph{UML Diagram} |
||
131 | |||
132 | \begin{center} |
||
133 | \fbox{\includegraphics[scale=1.0]{img/InstallerListener}} |
||
134 | \end{center}\ |
||
135 | |||
136 | \paragraph{Description} |
||
137 | |||
138 | \begin{itemize} |
||
139 | |||
140 | \item \textit{(constructor)} : only the default constructor will |
||
141 | be used. It is called from \texttt{Unpacker.run} before unpacking. |
||
142 | |||
143 | \item \texttt{beforePacks} will be called each time before an unpacking |
||
144 | call is performed. |
||
145 | |||
146 | \item \texttt{beforePack} is called before a package is |
||
147 | installed. Pack object and the number of the pack are passed. |
||
148 | |||
149 | \item \texttt{isFileListener} determines whether the next four |
||
150 | methods are called or not. This is a little performance optimizing. |
||
151 | |||
152 | \item \texttt{beforeDir} is called before a directory is created. |
||
153 | In this case, when file listeners exist, directories are created |
||
154 | recursively and the method is called at each step. The file and the |
||
155 | current \texttt{PackFile} object are passed. |
||
156 | \item \texttt{afterDir} is called directly after the directory |
||
157 | creation. |
||
158 | \item \texttt{beforeFile} is called before a file is created. The file |
||
159 | and \texttt{PackFile} object are passed as parameters. |
||
160 | \item \texttt{afterFile} is the best place to perform file |
||
161 | related actions. The given \texttt{PackFile} objects contains |
||
162 | the additional data which was set at packaging. |
||
163 | \item \texttt{afterPack} will be just called after the pack is |
||
164 | closed. |
||
165 | \item \texttt{afterPacks} is the last step before the handler |
||
166 | will be stopped. |
||
167 | \end{itemize}\ |
||
168 | |||
169 | \subsubsection{Custom Actions At Uninstalling Time} |
||
170 | |||
171 | \paragraph{UML Diagram} |
||
172 | |||
173 | \begin{center} |
||
174 | \fbox{\includegraphics[scale=1.0]{img/UninstallerListener}} |
||
175 | \end{center}\ |
||
176 | |||
177 | \paragraph{Description} |
||
178 | |||
179 | \begin{itemize} |
||
180 | |||
181 | \item \textit{(constructor)} : only the default constructor will |
||
182 | be used. It is called from \texttt{Destroyer.run} as first call. |
||
183 | \item \texttt{beforeDeletion} will be called after execute files was performed. |
||
184 | The given list contains all \emph{File} objects which are marked for deletion. |
||
185 | \item \texttt{isFileListener} determines whether the next two |
||
186 | methods are called or not. |
||
187 | \item \texttt{beforeDelete} is the method which, is called before |
||
188 | a single file is deleted. The \emph{File} object is given as |
||
189 | parameter. |
||
190 | \item \texttt{afterDelete} will be invoked after the delete call |
||
191 | for a single file. |
||
192 | \item \texttt{afterDeletion} is the last call before the |
||
193 | cleanup of created data is performed. |
||
194 | \end{itemize}\ |
||
195 | |||
196 | \subsection{Package Path} |
||
197 | Custom actions must always implement one of the given listener |
||
198 | interfaces. As mentioned above, it is also possible to derive from |
||
199 | one of the "Simple" listeners. The package path is facultative, only the |
||
200 | class name must be unique over all custom actions. The preparation of a |
||
201 | custom action for providing it with an installation is very similar to panels. |
||
202 | Custom actions must also be packed into a jar file with the name |
||
203 | of the custom action class name. This jar file should be placed in |
||
204 | \texttt{[IzPackRoot]/bin/customActions}, may be |
||
205 | \begin{verbatim} |
||
206 | [IzPackRoot]/bin/customActions/MyCompilerListener.jar |
||
207 | [IzPackRoot]/bin/customActions/MyInstallerListener.jar |
||
208 | [IzPackRoot]/bin/customActions/MyUninstallerListener.jar |
||
209 | \end{verbatim} |
||
210 | In the default Ant definition file (build.xml) there are some |
||
211 | targets for this stuff. |
||
212 | |||
213 | |||
214 | \subsection{Correlated Stuff} |
||
215 | \subsubsection{Native Libraries for Uninstallation} |
||
216 | If a custom action uses JNI at installation time, often the |
||
217 | associated uninstall custom action needs JNI too. For this |
||
218 | situation it is possible to declare a native library for |
||
219 | unstallation. The only work to do is to add a \texttt{stage} |
||
220 | attribute to the \texttt{native} tag in the install xml file like |
||
221 | \footnotesize |
||
222 | \begin{verbatim} |
||
223 | <!-- The native section. We specify here our os dependant |
||
224 | libs..--> <native type="3rdparty" |
||
225 | name="MyOSHelper.dll"stage="both" > |
||
226 | <os family="windows" /> |
||
227 | </native> |
||
228 | \end{verbatim} |
||
229 | \normalsize |
||
230 | |||
231 | The needed additional classes are packed into |
||
232 | lib/uninstaller-ext.jar. If a native library is defined for |
||
233 | uninstallation, this file will also be packed into the |
||
234 | installer.jar as IzPack.unistaller-ext and used at its right |
||
235 | position. |
||
236 | |||
237 | |||
238 | \section{What You Have To Do} |
||
239 | Follow the steps that are needed to create and use custom actions |
||
240 | with the "normal" source environment (not standalone compiler) |
||
241 | using Ant. Of course, it works also with the standalone compiler. |
||
242 | |||
243 | \subsection{\label{sec:caPackaging}Custom Actions at Packaging (CompilerListener)} |
||
244 | |||
245 | \begin{itemize} |
||
246 | \item Implement \texttt{com.izforge.izpack.event.CompilerListener} or |
||
247 | extend \texttt{com.izforge.izpack.event.SimpleCompilerListener}. |
||
248 | Place it as \texttt{[IzPackRoot]/src/lib/[MyPackagePath]/MyCompilerListener.java}. |
||
249 | |||
250 | \item Add a "compile.simple" antcall in to \texttt{[IzPackRoot]/src/build.xml}. |
||
251 | \footnotesize |
||
252 | \begin{verbatim} |
||
253 | <antcall target="compile.listener.simple"> |
||
254 | <param name="listener" value="MyCompilerListener"/> |
||
255 | <param name="listener-dir" value="MyCompilerListener"/> |
||
256 | <param name="listener-include" value="[MyPackagePath]"/> |
||
257 | </antcall> |
||
258 | \end{verbatim} |
||
259 | \normalsize |
||
260 | |||
261 | \item Run \texttt{[IzPackRoot]/src/build.xml}. |
||
262 | |||
263 | \item Add a "listeners" ELEMENT with a "listener" ELEMENT with |
||
264 | a "compiler" attribute in to [MyProjectPath]/install.xml |
||
265 | \footnotesize |
||
266 | \begin{verbatim} |
||
267 | <listeners> |
||
268 | <listener compiler="MyCompilerListener" /> |
||
269 | <listeners> |
||
270 | \end{verbatim} |
||
271 | \normalsize |
||
272 | |||
273 | \item Compile with |
||
274 | \footnotesize |
||
275 | \begin{verbatim} |
||
276 | java -jar [IzPackRoot]/lib/compiler.jar -HOME [IzPackRoot] |
||
277 | [MyProjectPath]/install.xml -b [MyProductPath] -o |
||
278 | [MyBuildPath]/install.jar |
||
279 | \end{verbatim} |
||
280 | \normalsize |
||
281 | |||
282 | \item Test it |
||
283 | \end{itemize}\ |
||
284 | |||
285 | \subsection{Custom Actions at Installation Time (InstallerListener)} |
||
286 | Perform the same steps as described in \ref{sec:caPackaging}, replace |
||
287 | all occurrences of "CompilerListener" with "InstallerListener" and |
||
288 | "compiler" with "installer". |
||
289 | |||
290 | \subsection{Custom Actions at Uninstallation Time |
||
291 | (UninstallerListener)} Perform the same steps as described in |
||
292 | \ref{sec:caPackaging}, replace all occurrences of |
||
293 | "CompilerListener" with "UninstallerListener"and "compiler" with |
||
294 | "uninstaller". |
||
295 | |||
296 | |||
297 | \section{Example} |
||
298 | Let us say, we want to set access rights for files and directories |
||
299 | on Unix. The Java sources are placed in the directory \\ |
||
300 | \texttt{[IzPackRoot]/sample/src/com/myCompany/tools/install/listener}. |
||
301 | There are the files ChmodCompilerListener.java and |
||
302 | ChmodInstallerListener.java. |
||
303 | \begin{itemize} |
||
304 | \item Copy the files too |
||
305 | [IzPackRoot]/src/lib/com/myCompany/tools/install/listener |
||
306 | \item In [IzPackRoot]/src/build.xml there are the lines |
||
307 | \footnotesize |
||
308 | \begin{verbatim} |
||
309 | <!-- CUSTOM ACTION test START |
||
310 | CUSTOM ACTION test END --> |
||
311 | \end{verbatim} |
||
312 | \normalsize Uncomment them (activate the lines between them). |
||
313 | \item Build IzPack new. |
||
314 | \item Compile a test installation with |
||
315 | \footnotesize |
||
316 | \begin{verbatim} |
||
317 | java -jar [IzPackRoot]/lib/compiler.jar -HOME [IzPackRoot] |
||
318 | [IzPackRoot]/sample/listener/install.xml |
||
319 | -b [IzPackRoot]/sample/listener -o |
||
320 | [IzPackRoot]/sample/listener/install.jar |
||
321 | \end{verbatim} |
||
322 | \normalsize |
||
323 | \item Install it |
||
324 | \footnotesize |
||
325 | \begin{verbatim} |
||
326 | java -jar install.jar |
||
327 | \end{verbatim} |
||
328 | \normalsize |
||
329 | \end{itemize}\ |
||
330 | |||
331 | |||
332 | \section{Ant Actions (InstallerListener and UninstallerListener)} |
||
333 | In this section the common ant task custom actions are described |
||
334 | in detail. It is only for developers who are not acquainted |
||
335 | with \texttt{IzPack} or it's custom actions. In addition to the |
||
336 | basics there are some recapitulations of the common custom |
||
337 | action techniques and some hints for pitfalls.\\ |
||
338 | In the package \texttt{com.izforge.izpack.event} there are the ant |
||
339 | related custom actions \texttt{AntActionInstallerListener} and |
||
340 | \texttt{AntActionUninstallerListener}. As recapitulation, to add |
||
341 | any custom action a |
||
342 | reference in install.xml will be needed, as example:\\ |
||
343 | \footnotesize |
||
344 | \begin{verbatim} |
||
345 | <listeners> |
||
346 | <listener installer="AntActionInstallerListener" |
||
347 | uninstaller="AntActionUninstallerListener" /> |
||
348 | </listeners> |
||
349 | \end{verbatim} |
||
350 | \normalsize |
||
351 | |||
352 | For all referenced listeners a jar file with the same name must |
||
353 | exist in \texttt{[IzPackRoot]/bin/customActions}. If compilation |
||
354 | (packaging) fails with a "not found" error, first |
||
355 | verify, that the jar file exists. If not, create it.\\ |
||
356 | With this custom action it is possible to perform ant calls at |
||
357 | installation and/or uninstallation time. It is not only a wrapper |
||
358 | for a comand-line ant call, but also an intersected description file |
||
359 | defining what target of the ant build file should be performed at |
||
360 | what time of (un)installation and specifies which properties for what IzPack |
||
361 | \texttt{pack} are to be used. The intersected description file is written as XML, |
||
362 | the corresponding dtd is placed in |
||
363 | src/dtd/event/antaction.dtd. The description file should be declared as a |
||
364 | resource in the install.xml with the id \texttt{AntActionsSpec.xml} e.g.\\ |
||
365 | |||
366 | \footnotesize |
||
367 | \begin{verbatim} |
||
368 | <resorces> |
||
369 | ... |
||
370 | <res id="AntActionsSpec.xml" src="myInstallSpecs/MyAntActionsSpec.xml" /> |
||
371 | ... |
||
372 | </resorces> |
||
373 | \end{verbatim} |
||
374 | \normalsize |
||
375 | |||
376 | The precise spelling of the id is important. The base path of \texttt{src} |
||
377 | is the installation project path. If you want to use ant, you have to specify it here. |
||
378 | IzPack is designed for running without dependencies on external software or libraries. |
||
379 | Therefore it is necessary to include everything needed, in this case ant self. |
||
380 | The field \texttt{<jar>} in |
||
381 | installation.xml is predestinated for such cases, e.g.\\ |
||
382 | \begin{verbatim} |
||
383 | <jar src="jar/ant/ant.jar" stage="both" /> |
||
384 | \end{verbatim} |
||
385 | \normalsize |
||
386 | |||
387 | Be aware, that an "extended" ant use needs more than one jar, for |
||
388 | example often \texttt{xercesImpl.jar}. If an obscure "class not |
||
389 | found" exception is raised during testing, check first for missing |
||
390 | jar files.\\ |
||
391 | For supporting uninstallation the jar field was extended by the |
||
392 | attribute \texttt{stage}. If an ant uninstaller custom action is |
||
393 | used, the uninstaller also needs the jar files. If \texttt{stage} |
||
394 | is "both" or "uninstall", the contents of the referenced jar file |
||
395 | will be packed into uninstaller.jar. Be aware that not the jar file |
||
396 | itself, but the contents of it are required. This implies, that the paths of the |
||
397 | contained files are unique and the information in |
||
398 | \texttt{meta-inf/Manifest.mf} will be lost.\\ |
||
399 | \subsection{The Basic XML Struture} |
||
400 | An ant action will be defined in the resource with the id |
||
401 | "AntActionsSpec.xml". Sometimes it will help to lock into |
||
402 | \texttt{[IzPackRoot]/src/dtd/event/antaction.dtd} or validate a |
||
403 | written xml file with the dtd.\\ |
||
404 | On this xml file a substitution will be performed using all |
||
405 | defined \texttt{IzPack} variables. It is performed just before |
||
406 | processing the packs. This is a common way of loading spec files |
||
407 | into custom actions. For more information see method |
||
408 | \texttt{com.izforge.izpack.util.SpecHelper.readSpec}. |
||
409 | If you want to substitute some custom item, simply add a variable |
||
410 | via idata.setVariable in a custom panel before \texttt{InstallPanel}. |
||
411 | The given variable name (id) should be written into the xml file |
||
412 | in the common variable notation.\\ |
||
413 | |||
414 | The top level XML section is called \texttt{<antactions>}. Only |
||
415 | one is possible. The \texttt{<antactions>} are segregated in one or more |
||
416 | \texttt{<pack>} elements. The single attribute \texttt{<name>} of |
||
417 | the \texttt{<pack>} corresponds to the same structure in |
||
418 | install.xml (for more information see also installation.dtd). Only the |
||
419 | "things" included in the \texttt{<pack>} are performed, if a |
||
420 | pack with the same name was chosen to be installed. The "things" |
||
421 | to be done to self are defined by the element \texttt{<antcall>} (without |
||
422 | ssss).\\ |
||
423 | The \texttt{<antcall>} takes the following attributes: |
||
424 | \begin{itemize} |
||
425 | \item \texttt{order}: required. Determine at what point of installation the antcalls |
||
426 | defined by element \texttt{target} should be |
||
427 | performed. Possible are |
||
428 | \texttt{beforepack}, \texttt{afterpack}, \texttt{beforepacks} or \texttt{afterpacks}. Be aware that |
||
429 | with beforepack(s) there are no installed files and also no installed |
||
430 | build file. With this order only preexistent build files are |
||
431 | useable. |
||
432 | |||
433 | \item \texttt{uninstall\_order}: optional. Determine at what point of uninstallation |
||
434 | the antcalls defined by element \texttt{uninstall\_target} |
||
435 | should be performed. Possible are \texttt{beforedeletion} |
||
436 | and \texttt{afterdeletion}. As opposed to the |
||
437 | behaviour of \texttt{order} the referenced files |
||
438 | are also accessible in the order |
||
439 | \texttt{afterdeletion}. The |
||
440 | uninstaller action copies the files into |
||
441 | tempfiles before deletion which are marked as deleteOnExit. |
||
442 | \item \texttt{quiet}: optional. To quit or not. Possible are yes or |
||
443 | no. Default is no. |
||
444 | \item \texttt{verbose}: optional. To output verbose information or not. Possible are yes |
||
445 | or no. Default is no. |
||
446 | \item \texttt{logfile}: optional. Path of the file for logging should |
||
447 | be performed. The logfile should be not marked for |
||
448 | uninstallation otherwise it will be deleted too. |
||
449 | \item \texttt{buildfile}: required. Path of the file which contains the |
||
450 | antcall. This is the file you normally use as \texttt{-buildfile} during an ant call via the command |
||
451 | line. In this file variables are not substituted. For |
||
452 | substitution there are properties in ant which can be used. |
||
453 | Never write an \texttt{IzPack} variable in an ant buildfile. |
||
454 | \item \texttt{messageid}: optional. A string ID which refers to \\ |
||
455 | \texttt{bin/langpacks/installer/<lang>.xml}. If it is defined, the message |
||
456 | will be displayed in the InstallPanel whilst performing the ant call. |
||
457 | \end{itemize} |
||
458 | In addition to the possible attributes there are some elements. All |
||
459 | elements can be defined more than one time in one |
||
460 | \texttt{<antcall>}. All are optional, but with no |
||
461 | \texttt{<target>} element the \texttt{<antcall>} makes no sense. |
||
462 | Do not confuse the following: "required"s are related to the |
||
463 | attributes of the elements, not to the elements themselfs. |
||
464 | \subsubsection{\label{tag:antproperty}\texttt{<property>}: define a property} |
||
465 | Property to be used with all \texttt{target}s and |
||
466 | \texttt{uninstall\_target}s which are defined for this antcall. |
||
467 | \begin{itemize} |
||
468 | \item \texttt{name}: required. The name (id) of the property. |
||
469 | \item \texttt{value}: required. The value of the property. |
||
470 | \end{itemize} |
||
471 | \subsubsection{\label{tag:antpropertyfile}\texttt{<propertyfile>}: define properties in a file} |
||
472 | Properties to be used with all targets and uninstall\_targets which |
||
473 | are defined for this antcall given by the path of a properties |
||
474 | file. |
||
475 | \begin{itemize} |
||
476 | \item \texttt{path}: required. Path of a file which contains |
||
477 | properties in the syntax which is used by ant. Some ant calls |
||
478 | need properties files. For these this element is used. One |
||
479 | way to fill specific data into it is to create a new file in |
||
480 | a custom panel and fill it with values given by input fields. |
||
481 | The file path can be set at installation time, if there is a |
||
482 | variable in AntActionSpec.xml and an IzPack variable was |
||
483 | defined before InstallPanel. That file can be only created |
||
484 | with deleteOnExit, if no \texttt{<uninstall\_target>} was defined in |
||
485 | this \texttt{<antcall>}. This implies, that other \texttt{<antcall>}s can |
||
486 | have a \texttt{<uninstall\_target>}. |
||
487 | \end{itemize} |
||
488 | |||
489 | \subsubsection{\label{tag:anttarget}\texttt{<target>}: target to call at installation} |
||
490 | Targets to perform with this antcall at installation time. The |
||
491 | targets should be defined in the given buildfile or else an ant |
||
492 | exception will be raised. This is that what you use, if you don't want |
||
493 | to perform the default target. e.g. cleaning the \texttt{IzPack} project with |
||
494 | \texttt{ant clean} |
||
495 | |||
496 | |||
497 | \begin{itemize} |
||
498 | \item \texttt{name}: required. The name of the target. |
||
499 | \end{itemize} |
||
500 | |||
501 | \subsubsection{\label{tag:antuninsttarget}\texttt{<uninstall\_target>}: target to call on uninstallation} |
||
502 | Targets to perform with this antcall at uninstallation time. The |
||
503 | targets should be defined in the given buildfile otherwise an ant |
||
504 | exception will be raised. With this target it will be possible |
||
505 | to undo the things done at installation time. |
||
506 | \begin{itemize} |
||
507 | \item \texttt{name}: required. The name of the uninstall target. |
||
508 | \end{itemize} |
||
509 |