Difference between revisions of "DSDP/MTJ/Build Process"

Revision as of 09:15, 11 January 2007

Create Builds Based on Right API Set

Short description:

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Create builds based on the right set of APIs

1. Brief Description

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.

The developer has possibly created preprocessing sections for certain device groups. During compilation/preprocessing the system checks whether the devices have the classes required in the code variation of the device. The connection between the device and the code is done through the preprocessing parameters defining either a single phone or a phone group. For the source code outside the preprocessing section the code is compared with the classes of all the build target phones. The builds are created if the code includes only the supported classes for each device. Notification is given about the devices and the code not supported.

2. Flow of events

2.1 Basic Flow

B1: The system shows options to choose the target devices for the build. The options are either individual devices or device groups.

B2: The user starts a build for

(1) one device

(2) several devices

B3: The system detects during preprocessing/compilation from the device database which APIs each device supports.

B4: The system creates the builds.

2.2 Alternative flows

Alternative flow 1: Not all the needed SDKs containing the APIs have been installed on PC.

Alternative flow 2: The devices belonging to the build target phones do not support the required APIs.

The system gives a warning message concerning the device models and the classes used which are not supported in the devices. The system does not create the build for the device group. The user can choose to either make the build without these certain devices or fix the source code.

Alternative flow 3: There are contradictions in the preprocessing code

The system gives a warning message during build concerning the device models which are in more than one device group in a same preprocessing section. This signals that there is a logic error in the preprocessing code. The system, however, creates the builds for the device groups in case the choice was intentional.

3. Special Requirements

4. Preconditions

4.1 The user has installed all the needed SDKs
The user has installed all the SDKs which contain the APIs needed in the builds.

4.2 The user has created preprocessing code
The user has created code sections into the code which is used only in relation to certain device groups. The device groups are defined in the device database.

4.3 The user has device database in use
The user has an up-to-date device database in use which covers all the devices referred to in the build. The database tells to the system which APIs each device supports.

4.4 The user has defined the target devices
The user has defined the target devices of the build. The system will compare the APIs in the device database on the source code only in relation to the target devices of the build.

5. Post Conditions

5.1 All the builds have been created
The system has created a build based on each variation.

5.2 API support is correct in the builds
The system has checked the API support for each target device. The user can be sure that all the target devices support the APIs mentioned in the source code of the build. If the device database is not up-to-date and the information about devices and the APIs is incorrect, the system would give a invalid outcome.

6. Extension Points

Comments:

Create Customer Branded Build

Short description:

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Create localized build

1. Brief Description

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.

A Java developer creates a build with a certain language support. The developer defines which languages need to be supported. The build is created based on the developer’s decisions and corrective checks are made into the build during the compilation.

2. Flow of events

2.1 Basic Flow

B1: The user chooses to create a new localization build in Eclipse.

B2: The system searches for the available localization configuration files and the localization files.

B3: The system shows the available localization configurations and also a list of all the available languages.

B4: The user defines which languages the build needs to support, he chooses

(1) one of the existing localization configuration

(2) to create a new set of languages by choosing languages from a list.

B5: The system checks during compilation that the localization code exists.

B6: The system checks during packaging that the needed localization text files exist.

2.2 Alternative flows

Alternative flow 1: The build does not include all the needed languages.

Alternative flow 1: The localization code does not exist.

3. Special Requirements

4. Preconditions

4.1 A localization support has been created
User has created localization support with at least all the needed languages. Localization support refers to the localization code, localization text, graphics, sounds and possible other files which define support for one or several languages.

5. Post Conditions

5.1 A localized build has been created
A localized build has been created based on a localization project.

5.2 A localization configuration file has been created
A localization configuration file has been created if the user did not use one of the existing localization configuration files but chose a new set of languages. The created localization configuration is reusable.

5.3 Language support is correct
The user can be sure that the language support in the build is correct.

6. Extension Points

Comments:

Create Localized Build

Short description:

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.

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Create localized build

1. Brief Description

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.

A Java developer creates a build with a certain language support. The developer defines which languages need to be supported. The build is created based on the developer’s decisions and corrective checks are made into the build during the compilation.

2. Flow of events

2.1 Basic Flow
B1: The user chooses to create a new localization build in Eclipse. B2: The system searches for the available localization configuration files and the localization files. B2: The system shows the available localization configurations and also a list of all the available languages. B3: The user defines which languages the build needs to support, he chooses (1) one of the existing localization configuration (2) to create a new set of languages by choosing languages from a list. B4: The system checks during compilation that the localization code exists. B5: The system checks during packaging that the needed localization text files exist.

2.2 Alternative flows

Alternative flow 1: The build does not include all the needed languages.

Alternative flow 1: The localization code does not exist.

3. Special Requirements

4. Preconditions

4.1 A localization support has been created
User has created localization support with at least all the needed languages. Localization support refers to the localization code, localization text, graphics, sounds and possible other files which define support for one or several languages.

5. Post Conditions

5.1 A localized build has been created
A localized build has been created based on a localization project.

5.2 A localization configuration file has been created
A localization configuration file has been created if the user did not use one of the existing localization configuration files but chose a new set of languages. The created localization configuration is reusable.

5.3 Language support is correct
The user can be sure that the language support in the build is correct.

6. Extension Points

Comments:

Create Device Specific Build

Short description:

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.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Create separate build for each device

1. Brief Description

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.

A Java developer creates separate jad- and jar-files for each device to be used in distribution. The developer chooses to create a release build and to use the optional feature of creating a separate jad- and jar-files for each device. The system does the compilation and creates all the variations. During packaging the system creates jad- and jar files with individual names for each device. The files are stored in folders containing each folder only one variation but many jar and jad files with individual names.

2. Flow of events

2.1 Basic Flow

B1: The user chooses to create a release build

B2: The system shows the option of creating a separate build for each device.

B3: The user chooses to use this option.

B4: The system compiles all the wanted software variations.

B5: The system packages the compilation results and creates individual build files for each device.

B6: The system names the files based on the compilation device groups.

B7: The system changes the url-links in the jad-files to conform to the new names of the jar-files.

B8: The system stores the files into folders containing each folder results from only one software variation.

2.2 Alternative flows

Alternative flow 1:

3. Special Requirements

4. Preconditions

4.1 The target devices have been defined
The user has defined the target devices of the build. The names of the target devices are used as the source for the file names of the individually named build files.

4.2 Preprocessing info is in use
The system has stored the device group information from the preprocessing. The system knows for which devices each build is meant for.

5. Post Conditions

5.1 Individually named builds are available for each device
The system has created builds based on the chosen software variations. The system has additionally created enough copies from these builds that an individually named build can be provided for each device. The file names consists of the given application name plus the name of the device e.g. Midlet_Nokia_5500.jar and Midelt_Nokia_5500.jad.

5.2 The url-links in the jad-files conform to the jar-names
The system has modified the url-links in the jad-files to conform to the names of the jar-files.

5.3 Builds are stored in folders containing one software variation
The system has stored the created builds into file folders containing builds basing on one software variation. The only differences between the builds in one folder are the names of the files and the url-link in the jad-file.

6. Extension Points

Comments:

Deploy Builds into Emulators

Short description:

A Java developer has a need to deploy builds into emulators to test the code during the application development. The deployment to emulators is done number of times, often hundreds of times during a project. The deployment configuration information should be reusable.

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Deploy builds into emulators

1. Brief Description

A Java developer has a need to deploy builds into emulators to test the code during the application development. The deployment to emulators is done number of times, often hundreds of times during a project. The deployment configuration information should be reusable. All the extra phases from the deployment should be removed.

A Java developer creates builds for different phones and deploys them straight into emulators. The Java developer creates builds from all the software versions he wants and the system creates builds from them. The system passes the builds straight into right emulators.

2. Flow of events

2.1 Basic Flow

B1: The system defines the available emulators for each software version/phone group based on device database.

B2: The user defines which builds should be used in the emulators.

B3: The user chooses to open the builds in the emulators.

B4: The system opens up the builds in the emulators.

B5: The system stores the information about the emulator deployment for reuse.

2.2 Alternative flows

Alternative flow 1: Transfer signed builds into emulators.

Alternative flow 2: User chooses the emulators to be used with the builds.

3. Special Requirements

4. Preconditions

4.1 The builds exist
The user has made the builds.

4.2 The device database exists with emulator information
There exists a device database with information about which emulators best fit with each device. This information can be modified by the user or the information can be overridden with user defined information.

4.3 The emulators are available
The emulators are available and they are integrated into Eclipse.

5. Post Conditions

5.1 The builds are opened in emulators
The system opens up the emulators for each build. The system opens up either one or several emulators per each build.

5.2 The emulator deployment procedure is reusable
The system remembers all the choices made during the deployment process: which builds are used with which emulators. In order to redo the build procedure the user can start it with just one click. The user can also modify the signing configuration if he wants.

6. Extension Points

Comments:

Remove Debug Features from Release Build

Short description:

Before releasing the SW build, debug information must be removed from the source code

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Remove debug features from release build

1. Brief Description

The duty of the Java developer when creating a release build is to make sure that the build is ready for release. One of the acts to fulfill this is to remove the debug features from the build.

A Java developer chooses from the build operations that the build is a release build. The system removes all debug features during the preprocessing.

2. Flow of events

2.1 Basic Flow

B1: The user starts to make build

B2: The user chooses between

(1) development build

(2) release build

B3: The user chooses to build a release build

B4: The system starts the compiling and detects during the preprocessing all the debug classes.

B5: The system removes the debug classes and their methods and replaces some methods.

B6: The system creates the release build without the debug features

2.2 Alternative flows

Alternative flow 1: The user chooses a development build.

3. Special Requirements

4. Preconditions

4.1 Debug classes marked as debug classes
A Java developer has marked all the debug classes as debug classes

4.2 Alternative methods are defined
A Java developer has defined alternative methods for the methods in debug classes needing to be replaced with something.

5. Post Conditions

5.1 Release build has been created without debug features
The user has created the release build for sure without debug features. The user can continue with the build into the next steps of the deployment process without a risk of accidentally releasing a debug build.

6. Extension Points

Comments:

Sign all versions at once

Short description: A developer is able to sign several build using one command

Priority:

Owner:

Status: Proposed, Outlined

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use Case Specification: Sign all versions at once

1. Brief Description

A Java developer has a need to sign the application several times during the application development. The signing of the application makes it possible to test the application in a state resembling the release version. The more there are different builds the more it takes time. In case of an application with large device support hundreds of builds are signed during a project. The signing configuration information should be reusable. All the extra phases from the signing should be removed.

A Java developer signs all builds at once. The Java developer selects as many builds as he likes and signs all the versions with all the signing certificates he wants at once.

2. Flow of events 2.1 Basic Flow

B1: The user chooses the builds to be signed.

B2: The user defines where builds can be found.

B3: The user marks the certificate which he wants to use with each version.

B4: The user defines where each code-signing certificate can be found from the file hierarchy.

B5: The user starts the signing.

B6: The system creates all signings for the chosen builds.

B7: The system stores the information about the signing for reuse.

2.2 Alternative flows

Alternative flow 1:

3. Special Requirements

4. Preconditions

4.1 All code-signing certificates are available
The user has all the needed code-signing certificates from Certificate Authorities (CA) as well as other certificates in his use.

5. Post Conditions

5.1 The versions embody the version specific hash strings
The system has included the version specific hash strings in the jad-files of the builds.

5.2 The versions embody all the wanted certificates
The system has included all the wanted certificates into the jad-files of the builds. The order of the certificates has been chosen if wanted.

5.3 The signing procedure is reusable
The system remembers all the choices made during the signing process: which builds should be signed, the places of the signing files etc. In order to redo the signing procedure the user can start it with just one click. The user can also modify the signing configuration if he wants.

6. Extension Points

Comments:

Generate build scripts for Ant

Short description: Java developer uses system to export an Ant build script that can be used with Ant to build software from Eclipse or from command line.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use-Case Specification: Generate build scripts for Ant

1. Use Case Description In order to use Ant to build software, Java developer is required to have a build script. This script can be automatically generated by the system.

The developer has defined the target devices for the software. Optionally the developer might have also defined preferred obfuscator and preprocessor. The developer chooses to export Ant build files. The system checks that required API classpaths are found, generates Ant build files with correct Ant targets, classpaths and options for the target devices. If some of the required classpaths are missing the developer is informed and operation aborted.

After succesfully generating the build scrips the developer can build software by using Ant from Eclipse or from command line.

2. Basic Flow

B1: The user chooses to create new Ant build files.

B2: The system verifies that classpaths for all required APIs are found (see Missing classpaths for required APIs have been found).

B3: The system adds classpaths automatically to the Ant build files (see Optionally adding obfuscator and preproccesor).

B4: The system saves the Ant build files in the project folder.

3. Alternate Flows

Missing classpaths for required APIs have been found:

A1: The system aborts generating Ant build scripts and informs user on the missing classpaths.

Optionally adding obfuscator and preprocessor:

A1: If the developer defined preferred obfuscator and preprocessor then Ant targets for obfuscation and preprocessing are added in the build script.

A2: The system saves the Ant build files in the project folder.

4. Preconditions 4.1 A project has been created. 4.2 Target devices for project have been defined.

5. Postconditions 5.1 Ant build scripts for selected target devices have been created in the project folder. 5.2 Build scripts contain correct classpaths for the selected target devices.

6. Extension Points

7. Special Requirements

8. Additional Information 8.1 The developer is required to generate new Ant build files each time target devices, used obfuscator or used preprocessor are redefined.

Comments:

Create preprocessed build with Ant

Use Case Specification: Create preprocessed build with Ant

Back to main DSDP-MTJ Use Cases

Short description: Preprocessing is used to solve fragmentation problems caused by multiple target devices. The system can preprocess source code for each of the devices before building the actual software.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use-Case Specification: Create preprocessed build with Ant

1. Use Case Description Preprocessing can be used to solve fragmentation problems caused by multiple target devices supporting different APIs. Preprocessing definitions can be written in source code to include different APIs or Java commands where applicable and then they're processed during preprocessing to include correct Java commands that are finally compiled during build.

Used preprocessor for the software has been configured by the developer and correct preprocessing definitions have been created in the source code. The developer has generated required build scripts using the system (see use case: Generate build scripts for Ant). During build Ant first preprocesses source code to select correct codes for the defined target device. Then the preprocessed source code is compiled and finally the build is created.

2. Basic Flow

B1: User selects if he wants to use Ant from Eclipse or from command line

B2: User starts Ant with correct Ant target.

B3: The system preprocesses Java source code (see Preprocessor not found by Ant).

B4: The system compiles preprocessed Java source code.

B5: The system packages resulting preprocessed bytecode in the build Jar file.

3. Alternate Flows

Preprocessor not found by Ant:

A1: If the default preprocessor is not found by Ant the system aborts generating build and informs user on the error.

4. Preconditions 4.1 A project has been created. 4.2 Target device for project have been selected. 4.3 Default preprocessor for project has been selected. 4.4 Build scripts for Ant have been generated.

5. Postconditions 5.1 Preprocessed build for selected target device has been created in a named folder.

6. Extension Points

7. Special Requirements 7.1 Ant is installed on system and preferably in the system path for command line support.

8. Additional Information The system can be configured with several different preprocessors. Only one of them can be used at time by the Ant. If the default preprocessor is changed the Ant build scripts are needed to be rebuilded before it can be used with Ant. Different preprocessors might require different kind of definitions to make preprocessing possible.

Comments:

Create obfuscated build with Ant

Use Case Specification: Create obfuscated build with Ant

Short description:

Obfuscation is important for minimizing the Jar file size when developing J2ME applications. The system can perform obfuscation during build process.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use-Case Specification: Create obfuscated build with Ant

1. Use Case Description Obfuscation is useful method to minimize Jar file size for J2ME software used in the devices where memory is limited. Obfuscator detects and removes unused classes, fields, methods, and attributes. It also renames remaining classes by using short, meaningless names. The resulting bytecode is much smaller than the original would have been and as such better for use in limited devices.

The default obfuscator for the software has been defined by the developer and correct Ant target has been created during Ant build script generation (see use case: Generate build scripts for Ant). During build Ant compiles source code into bytecode, which is then processed by the obfuscator. Finally the obfuscated bytecode is packaged in a Jar file.

2. Basic Flow

B1: User selects if he wants to use Ant from Eclipse or from command line

B2: User starts Ant with correct Ant target.

B3: The system compiles Java source code.

B4: The system obfuscates Java bytecode (see Obfuscator not found by Ant).

B5: The system packages resulting obfuscated bytecode in the build Jar file.

3. Alternate Flows

Obfuscator not found by Ant:

A1: If the default obfuscator is not found by Ant an error is given to the developer and build aborted.

4. Preconditions 4.1 A project has been created. 4.2 Target device for project have been selected. 4.3 Default obfuscator for project has been selected. 4.4 Build scripts for Ant have been generated.

5. Postconditions 5.1 Obfuscated build for selected target device has been created in a named folder.

6. Extension Points

7. Special Requirements 7.1 Ant is installed on system and preferably in the system path for command line support.

8. Additional Information The system can be configured with several different obfuscators. Only one of them can be used at a time by the Ant. If default obfuscator is changed the Ant build scripts are needed to be rebuilded before it can be used with Ant.

Comments:

Create builds based on right set of APIs with Ant

Use Case Specification: Create builds based on right set of APIs with Ant

Back to main DSDP-MTJ Use Cases

Short description: It is useful for Java developer to be able to build software for multiple target devices at the same time. The system can automatically create builds based on the right sets of APIs for each target device.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use-Case Specification: Create builds based on right set of APIs with Ant

1. Use Case Description It is useful for Java developer to be able to build software for multiple target devices or target device groups at the same time. To make this possible the system is required to be able to use different classpaths for different builds as different devices might use different API sets.

The developer has generated required build scripts using the system (see use case: Generate build scripts for Ant). The developer decides to create new build for all target devices. During build Ant processes all the generated target device Ant targets and creates build for each of them using the right classpaths. The builds are stored in their own folders defined by the target device or group name.

2. Basic Flow

B1: User selects if he wants to use Ant from Eclipse or from command line

B2: User starts Ant with correct Ant target.

B3: The system compiles Java source code for each target device with correct classpath and creates build for each target device.

B4: The system saves the builds into folders named by the target devices.

3. Alternate Flows

4. Preconditions 4.1 A project has been created. 4.2 Target devices or groups have been defined for project. 4.3 Build scripts for Ant have been generated.

5. Postconditions 5.1 Builds for selected target devices have been created in named folders. 5.2 Builds are created using correct classpaths.

6. Extension Points

7. Special Requirements 7.1 Ant is installed on system and preferably in the system path for command line support.

8. Additional Information 8.1 Using Ant from command line makes building software possible on environments where only command line access is available. This might be useful for example to automate build process on server. Some developers also prefer working on command line instead of GUI SDK.

Comments:

Run build in emulator with Ant

Use Case Specification: Run build in emulator with Ant

Short description: It is useful for Java developer to be able to run software in a emulator directly from the development environment. The system can automatically create build and start it in the emulator.

Priority:

Owner:

Status:

Proposed:|Accepted: date_here

Identified|Described|Outlined|Detailed

Community Review: review_date_here

Use-Case Specification: Run build in emulator with Ant

1. Use Case Description It is useful for Java developer to be able to run software in a emulator directly from the development environment. This makes development cycles faster and minimizes work steps required for the developer.

The developer has defined emulator as default target device for the project. The developer has generated required build scripts using the system (see use case: Generate build scripts for Ant). The developer decides to run new build in the emulator. The system builds the software with correct classpaths and runs it in the emulator.

2. Basic Flow

B1: User selects if he wants to use Ant from Eclipse or from command line

B2: User starts Ant with correct Ant target.

B3: The system compiles Java source code and creates Jar file.

B4: The system launches Jar file in the emulator (see Emulator not found by Ant).

3. Alternate Flows

Emulator not found by Ant:

A1: If the defined emulator is not found by Ant an error is given to the developer and operation is aborted.

4. Preconditions 4.1 A project has been created. 4.2 Emulator has been selected as target device for project. 4.3 Build scripts for Ant have been generated. 4.4 Selected emulator is installed on the system.

5. Postconditions 5.1 Emulator is started with built software running in it.

6. Extension Points

7. Special Requirements 7.1 Ant is installed on system and preferably in the system path for command line support.

8. Additional Information If the default emulator is changed the Ant build scripts are needed to be rebuilded before it can be used as run target with Ant.

Comments: