Creating Properties Files for Your Providers

Using the recommended spring dependency injection mechanism, as shown in the included examples, create separate properties files for provider definition and provider instance-specific parameters as follows:

Designating the Details for Each Provider

Using the spring dependency injection mechanism, you define your provider’s class and its parameter definition, but not values, in an XML definition file.

For example, Serena provides the provider-dm.xml file for Dimensions CM, a potential provider of DCRs and DUs and provider-sbm.xml file for SBM, a potential provider of RFCs, BCRs, and DCRs.

The following example implements the spring dependency injection mechanism for a simple file system provider.



<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns=""







   <!-- enable processing of annotations such as @Autowired and @Configuration -->


   <context:component-scan base-package="com.serena.rlm.provider.fs"/>


    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">

       <property name="ignoreUnresolvablePlaceholders" value="true"/>

       <property name="order">





   <bean id="requestsProvider" class="com.serena.rlm.provider.fs.FSRequestsProvider">

       <property name="providerName" value ="${}"/>

       <property name="providerDescription" value ="${requests.provider.description}"/>

       <property name="requestsFile" value ="${provider.fs.requests.file}"/>




    <bean id="deployUnitsProvider" class="com.serena.rlm.provider.fs.FSDeployUnitsProvider">

       <property name="providerName" value ="${}"/>

        <property name="providerDescription" value ="${deploy.units.provider.description}"/>

       <property name="depunitsFile" value ="${provider.fs.depunits.file}"/>

       <property name="stagesFile" value ="${provider.fs.stages.file}"/>

       <property name="depareaFile" value ="${provider.fs.deparea.file}"/>




Telling Serena Release Manager to Use This Provider

Using the spring dependency injection mechanism, you define all instance-specific values for parameters in a properties file.

It is not required to use a properties file separate from the xml file in the provider implementation. However, usage of a properties file is a good practice and is included in the example provided. Using a properties file allows you to define several possible configurations so you can easily change details without code modification. Without a properties file, you must hard code name, description, and other specific parameters for your provider.


# requests provider definitions = filesystem

requests.provider.description = Simple file-system Request Provider


# deploy units provider definitions = filesystem

deploy.units.provider.description = Simple file-system Deployment Unit Provider







The text files referenced in the preceding example, requests.txt, depunits.txt, stages.txt, and areas.txt are shown in the following examples. This is a simple file-system example where the content of these could be populated by any mechanism you implement, such as JDBC, Web services, and other protocols.


# list of mocked requests should be defined here

# use the following format

# <request_id>|<request_name>|<request_status>|<request_url>

ECR0001|Old delete icon in POA toolbars|Assigned to QA|

ECR0002|WEB-Cannot set owner for a project|Closed|

ECR0003|Approved dialog from Project node inconsistent to the same functionality on Area|Code & Unit Test|


# list of mocked deployment units should be defined here

# use the following format

# <depunit_id>|<depunit_name>|<depunit_project_name>

DEP0001|Deployment unit 1|FS:RLM_TEST_1

DEP0002|Deployment unit 2|FS:RLM_TEST_2

DEP0002|Deployment unit 3|FS:RLM_TEST_3


# list of mocked stages should be defined here

# use the following format

# <stage_id>|<stage_name>|<stage_projects>



# list of mocked areas should be defined here

# use the following format

# <area_id>|<area_name>|<area_directory>|<area_stage_id>|<area_status>|<depunit_project_name>

AR0001|Dev area|c:\work\|SIT|Open|QLARIUS:RLM_TEST

AR0002|Dev area|c:\work2\|SIT|Open|QLARIUS:RLM_TEST2