|
587
|
1 |
System Definition v3 support
|
|
|
2 |
============================
|
|
|
3 |
|
|
|
4 |
Helium is now supporting System Definition v3 to achieve build. This document explains how to configure Helium and
|
|
|
5 |
how input files are handled in the tool.
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
How to configure the feature?
|
|
|
9 |
-----------------------------
|
|
|
10 |
|
|
628
|
11 |
In order to enable the support you first need to define the **sysdef3.enabled** property to true. Then define a resource ant element to either
|
|
587
|
12 |
point to root definition file or package_definition.xml file.
|
|
|
13 |
|
|
|
14 |
e.g:
|
|
|
15 |
::
|
|
|
16 |
|
|
|
17 |
<path id="system.definition.files">
|
|
|
18 |
<pathelement path="${build.drive}/sf_sytem_definition.xml" />
|
|
|
19 |
<fileset dir="${build.drive}" includes="root/*/*/package_definition.xml" />
|
|
|
20 |
</path>
|
|
|
21 |
|
|
|
22 |
|
|
|
23 |
The previous example shows how you can configure your build to includes packages pointed by the sf_sytem_definition.xml, and a
|
|
|
24 |
set of additional packages directly referenced (root system definition will then be generated automatically, see package_map.xml section).
|
|
|
25 |
|
|
|
26 |
|
|
|
27 |
Package_map.xml
|
|
|
28 |
---------------
|
|
|
29 |
|
|
|
30 |
The package_map.xml provides mapping information between the package and it physical location under the build environment. The following
|
|
|
31 |
example show how to write a package_map.xml file for a package that should be placed under sf/mw:
|
|
|
32 |
|
|
|
33 |
::
|
|
|
34 |
|
|
|
35 |
<?xml version="1.0"?>
|
|
|
36 |
<PackageMap root="sf" layer="mw" />
|
|
|
37 |
|
|
|
38 |
This information is also required to build from package_definition.xml file directly, so a valid root system model file can be generated
|
|
|
39 |
automatically.
|
|
|
40 |
|
|
|
41 |
|
|
|
42 |
The package_map.xml must be placed under the root directory of the package. **package_definition.xml** without package_map.xml are considered
|
|
628
|
43 |
as invalid by the copying step and the automatic root system definition file generation. Only exception to that rule is for the vendor
|
|
|
44 |
package_definition.xml which must be placed exactly two level under the root of the package.
|
|
587
|
45 |
|
|
|
46 |
Example of package structure:
|
|
|
47 |
::
|
|
|
48 |
|
|
|
49 |
+ <root>
|
|
|
50 |
+ <layer>
|
|
|
51 |
+ <package>
|
|
|
52 |
- package_definition.xml
|
|
|
53 |
- package_map.xml
|
|
|
54 |
+ component
|
|
|
55 |
+ nokia_<component>_metadata
|
|
|
56 |
- package_definition.xml
|
|
|
57 |
|
|
|
58 |
|
|
|
59 |
|
|
|
60 |
Canonical system definition generation workflow
|
|
|
61 |
-----------------------------------------------
|
|
|
62 |
The following diagram describes the workflow of the canonical System Definition file generation.
|
|
|
63 |
|
|
|
64 |
.. image:: sysdefv3_workflow.png
|
|
|
65 |
:align: center
|
|
|
66 |
|
|
|
67 |
The input of the workflow is the Ant resource identified by the **system.definition.files** id. Its content is then divided in two parts:
|
|
|
68 |
* package_definition.xml files
|
|
|
69 |
* other files considered as root system definition file.
|
|
|
70 |
|
|
|
71 |
The package_definition.xml (and package_map.xml) will be used to generated a root system file, which will be used
|
|
|
72 |
as any other root system definition file. The package_definition.xml will then be ignored from other operations.
|
|
|
73 |
|
|
|
74 |
Then workflow converges into the following regular operations:
|
|
|
75 |
* joining each root system definition file into standalone model.
|
|
|
76 |
* merging each root files.
|
|
|
77 |
|
|
|
78 |
The order of merging is defined by the order inside the resource, so to guaranty that order it is advised to use Ant path
|
|
|
79 |
element rather than filesets. Also the generated model is always included at then end.
|
|
|
80 |
|
|
|
81 |
|