Step

Action

2

Select the Configure Build Service Mappings function from the Openmake menu.

3

In the Build Service Mappings window, you will see a list of all available Build Service Mappings, including the default mappings, and any mappings that were configured by you. Click the New button to create a new Build Service mapping.

4

In the Nature Mappings window you will see a list of Mapping categories that your Mappings are associated with. All default mappings that came with the plug-in installation are associated with the StandardMappings category. It is recommended that you create a new category for your new Mapping. Fill in a new Mapping category name, or select an existing category to associate your mapping.

5

In the Build Service Selection window, enter a name for the new Build Service Mapping, and select the Operating System and Build Service that you want to map.

Set the permissions on the mapping by checking or unchecking the Only allow Administrators to edit or remove this Mapping box.

Select whether the mapping will support circular dependencies by checking or unchecking the This Mapping supports Projects with circular dependencies box.

Note: Mappings that support circular dependencies are not available for use with Projects that are not circular dependencies of other projects. Mappings that do not support circular dependencies are not available for use with Projects that contain circular dependencies.

6

Fill in the description of the Build Service mapping with text that will describe the function of the Build Service Mapping to other developers.

7

Click Next.

8

In the Mapping Definition window, select the Build Tasks and Option Groups associated with the Build Service that you are mapping.

9

Select the Mapping Type to be used.

"Classpath" Mapping Type is used to associate a Build Task with a classpath or build path definition.

"Compile" Mapping Type associated a Build Task with compilation of source code using the javac compiler.

"Archive" Mapping Type is used to associate a Build Task with any archive task, such as bundling compiled code and resource files into a .war, .jar, or .ear files.

"Filter" is a special Mapping Type that is only used when you are attempting to build a project that contains circular dependencies.

10

The Includes and Exclude Patterns indicate where the plug-in should look for dependencies when generating Target Definitions and which dependencies it should exclude from Target Definitions.

Include pattern will include the dependency in the build.  Exclude pattern will exclude the dependency from the build.

Use the Macro button to insert the pre-defined macros into the Include and Exclude Patterns.  See Table SI-5 for the macro definitions.

11

Use the Add button to the right of the Include Patterns field to Include Patterns that aren't defined by Macros.  See Table SI-6 for creating new patterns.

12

Click Finish once you have completed your Build Service Mappings, including Mapping Types and Include and Exclude Patterns for each Build Task.

The new Build Service Mapping will be available to apply to each referenced project in your Build Project.

Macro

Definition

$(PROJECT)

Root of an Eclipse or Rational Application Developer project

$(PROJECT)\$(SRC_FOLDERS)

Location of a projects source code. This is useful for Compile Mapping Types

$(PREVIOUS_TASK_RESULTS)

Location of the results (or targets) of the previous Build Task. For example, if we have an Archive step after a Compile task, we would add $(PREVIOUS_TASK_RESULTS) so that we can include any compiled classes in our Archive step, without having to define the locations that the classes were compiled to.

$(PROJECT_DEPLOY_LIBS)

Location where non-classpath libraries are located, such as run-time libraries that would be included in .war file for deployment.

$(BUILD_PATH_LIBS)

Location of classpath libraries for compilation. The locations of these libraries are defined in the Build Path for the project. The Eclipse plug-in will read in the location of the Build Path libs, and define this Macro accordingly.

$(PROJECT_REFERENCES)

Denotes targets that are created by projects that exist as dependencies of the referenced project. For instance, if I have two projects Foo and Bar where Foo creates foo.jar, and Bar creates bar.war and Bar references foo.jar as a dependency then the $(PROJECT_REFERENCES) macro will ensure that foo.jar is included as a dependency of the target generated for the Bar project.

Step

Action

1

Click the Add button to the right of the Include Patterns field. In the Enter a Dependency Pattern window, you can define other locations and file types that you want to include through Include Patterns.

2

Select the type of matching: Starts With, Ends With, Exact Match, and Contains

3

Click the Browse button to bring up a Folder Selection window for Browsing. The Folder Selection window is limited to your workspace. Browse down through your projects to find the location you want to apply to your Include Pattern. The project name will be replaced with the $(PROJECT) macro, to make the Include Pattern reusable across projects.

Note: You can also further narrow your Include Pattern by selecting a file type. The file type drop down window is populated by File Extensions that are defined in the Build Service.

4

Check the Limit to Longest Pattern Match box to restrict the dependencies to a single file location that has the longest pattern match.

For example, if you have a foo.jar file that you want to include in a .war file, and foo.jar exists in both $(PROJECT)\lib and $(PROJECT)\WEB-INF\lib, then the Include Pattern will only include the $(PROJECT)\WEB-INF\lib location, since it is the longest pattern match.

If you want to include multiple locations of the same file, then uncheck the Limit to Longest Pattern Match box.

5

Click OK. The Include Pattern is now available to the Mapping Definition.

Step

Action

1

Right click on the Eclipse project.

2

Select Openmake > Custom Build Service Mapping