Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/MTJ/Build Process"
| Line 1: | Line 1: | ||
[[Create Builds Based on Right API Set]]<br/> | [[Create Builds Based on Right API Set]]<br/> | ||
| − | : | + | :It is useful for the Java developer to know that the builds he is making are supported by the classes in the target phones. The system can create this information during compilation by using the device database information. The goal is that the developer creates only builds for each device based on the right set of APIs. |
| + | |||
[[Create Customer Branded Build]]<br/> | [[Create Customer Branded Build]]<br/> | ||
| − | : | + | :In order to create slightly different versions of the same software, the user must create a branded build. In a branded build the user can replace files from the main project and define code sections to be executed only in this branding subproject. |
| + | |||
[[Create Localized Build]]<br/> | [[Create Localized Build]]<br/> | ||
| − | : | + | :In order to control the amount of resource files in one build the java developer wants to create separate builds for different language areas. Into each build a set of supported languages are included which might cover for example a certain market. |
| + | |||
[[Create Device Specific Build]]<br/> | [[Create Device Specific Build]]<br/> | ||
| − | : | + | :The distributor of the application requests a separate jad- and jar-files for each supported device. The creation of the separate files is simple work and this can by automated by the help of the system. |
| + | |||
[[Deploy Builds into Emulators]]<br/> | [[Deploy Builds into Emulators]]<br/> | ||
| − | : | + | :During a project the build must be deployed several times into an emulator. Use case describes reusable deployment configuration. |
| + | |||
[[Remove Debug Features from Release Build]]<br/> | [[Remove Debug Features from Release Build]]<br/> | ||
| − | : | + | :A developer chooses to remove debug information from the source code while preprocessing. |
| + | |||
[[Sign all versions at once]]<br/> | [[Sign all versions at once]]<br/> | ||
| − | : | + | :A developer is able to sign several build using one command |
Revision as of 09:43, 10 November 2006
Create Builds Based on Right API Set
- It is useful for the Java developer to know that the builds he is making are supported by the classes in the target phones. The system can create this information during compilation by using the device database information. The goal is that the developer creates only builds for each device based on the right set of APIs.
- In order to create slightly different versions of the same software, the user must create a branded build. In a branded build the user can replace files from the main project and define code sections to be executed only in this branding subproject.
- In order to control the amount of resource files in one build the java developer wants to create separate builds for different language areas. Into each build a set of supported languages are included which might cover for example a certain market.
- The distributor of the application requests a separate jad- and jar-files for each supported device. The creation of the separate files is simple work and this can by automated by the help of the system.
- During a project the build must be deployed several times into an emulator. Use case describes reusable deployment configuration.
Remove Debug Features from Release Build
- A developer chooses to remove debug information from the source code while preprocessing.
- A developer is able to sign several build using one command