|
1 ########################### |
|
2 Helium Architecture |
|
3 ########################### |
|
4 |
|
5 .. index:: |
|
6 module: Helium Architecture |
|
7 |
|
8 |
|
9 .. contents:: |
|
10 |
|
11 Introduction |
|
12 ============ |
|
13 |
|
14 .. raw:: html |
|
15 :file: helium_overview.html |
|
16 |
|
17 This is a overview of the Helium toolkit and its dependencies as a stack. |
|
18 |
|
19 .. index:: |
|
20 single: Architectural Principles |
|
21 |
|
22 Architectural principles |
|
23 ======================== |
|
24 |
|
25 **Favour reusing existing software over writing new code.** There is a lot of useful open-source software available. If the license is sufficiently open it is better to use what exists. Development of new features should check for any existing software that may fulfill some or all of the implementation requirements. |
|
26 |
|
27 **Favour reusable libraries over standalone scripts.** Object-orientated programming and the development of libraries encourages reusability, reduced maintenance and higher quality. |
|
28 |
|
29 **Develop unit tests for testing the libraries.** Unit testing is important for regression testing and for agile development within a team. A developer can make changes and have confidence that no functionality has broken by running the unit tests. |
|
30 |
|
31 **Prefer platform independence.** The selection of tools and the development of libraries and scripts is done in a way that maximises independence from the underlying OS or hardware platform. Where specific dependencies are required they are configurable. Shell commands should be restricted to the set supported by the Unix Utils package on Windows, to ensure compatibility between Linux and Windows. |
|
32 |
|
33 .. index:: |
|
34 single: Archtectural References |
|
35 |
|
36 References |
|
37 ---------- |
|
38 |
|
39 * The Pragmatic Programmer, Andrew Hunt and David Thomas. See the `list of tips`_. |
|
40 |
|
41 .. _`list of tips` : http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html |
|
42 |
|
43 |
|
44 .. index:: |
|
45 single: Architectural Practices |
|
46 |
|
47 Practices |
|
48 ========= |
|
49 |
|
50 Files created in Ant, Perl, Python or XML syntax must follow the `Style guide <coding_conventions.html>`_. |
|
51 |
|
52 |
|
53 .. index:: |
|
54 single: Architectural Configuration |
|
55 |
|
56 Configuration |
|
57 ============= |
|
58 |
|
59 XML is recommended for defining configuration files. Ant configuration types and tasks should be used where most logical. If a more structured configuration is needed then a custom XML schema can be defined. Existing schemas should be reused where possible. |
|
60 |
|
61 (add existing schemas) |
|
62 |
|
63 .. index:: |
|
64 single: APIs |
|
65 |
|
66 APIs |
|
67 ========= |
|
68 |
|
69 See the reference API documentation: |
|
70 |
|
71 * `Helium API`_ |
|
72 * `Java APIs`_ |
|
73 * `Python APIs`_ |
|
74 * `Custom Ant tasks`_ |
|
75 |
|
76 .. _`Helium API` : api/helium/index.html |
|
77 .. _`Java APIs` : api/java/index.html |
|
78 .. _`Python APIs` : api/python/index.html |
|
79 .. _`Custom Ant tasks` : api/ant/index.html |
|
80 |
|
81 |
|
82 .. index:: |
|
83 single: Tools and scripts locations |
|
84 |
|
85 Tools and scripts locations |
|
86 =========================== |
|
87 |
|
88 All tools used by Helium (which means called by Ant at some point during a build sequence, directly or indirectly) come from one of these locations: |
|
89 |
|
90 * **Inside /helium/tools**. Content is generally developed or imported by the Helium team and is our responsibility. We strive to test it using unit tests where possible and general build execution. It should follow Helium coding guidelines. This may be libraries closely integrated with Ant, or standalone tools called by Ant like iCreatorDP. |
|
91 * **Inside /helium/external**. These are tools provided by an external party, which could be open source projects or other teams in Nokia. Updates are the responsibility of the maintainer. Typically Helium developers will import the updates, but if agreed the supplier might also directly make the update. If the content is currently provided as a Synergy project it is desirable to simply use releases of that. |
|
92 * **Inside /epoc32**. This covers the Symbian toolchain, iMaker, etc. At the point where the tool is needed it should have been exported into /epoc32. |
|
93 * **Already Installed**. All language runtimes such as Java, Perl and Python. |
|
94 |
|
95 .. index:: |
|
96 single: Dependency Diagram |
|
97 |
|
98 Dependency Diagram |
|
99 ================== |
|
100 |
|
101 .. image:: images/dependencies.grph.png |