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.

Example

provider-fs.xml

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

<beans xmlns="http://www.springframework.org/schema/beans"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xmlns:context="http://www.springframework.org/schema/context"

    xmlns:util="http://www.springframework.org/schema/util"

    xsi:schemaLocation="http://www.springframework.org/schema/beans

        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

        http://www.springframework.org/schema/context

        http://www.springframework.org/schema/context/spring-context-3.0.xsd

        http://www.springframework.org/schema/util

        http://www.springframework.org/schema/util/spring-util-3.0.xsd"

        default-lazy-init="true">

 

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

   <context:annotation-config/>

   <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">

           <value>1</value>

       </property>

   </bean>

 

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

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

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

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

   </bean>

    

    

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

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

        <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}"/>

   </bean>

 

</beans>

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, use 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, enabling you to change details without code modification. Without a properties file, you must hard code name, description, and other specific parameters for your provider.

Examples

fs_example.properties

# requests provider definitions

requests.provider.name = filesystem

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

 

# deploy units provider definitions

deploy.units.provider.name = filesystem

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

 

#

provider.fs.requests.file=requests.txt

provider.fs.depunits.file=depunits.txt

provider.fs.stages.file=stages.txt

provider.fs.deparea.file=areas.txt

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.

requests.txt

# 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|http://almmashups.serena.com/tmtrack/tmtrack.dll?IssuePage&RecordId=78506&Template=view&TableId=1000

ECR0002|WEB-Cannot set owner for a project|Closed|http://almmashups.serena.com/tmtrack/tmtrack.dll?IssuePage&RecordId=78501&Template=view&TableId=1000

ECR0003|Approved dialog from Project node inconsistent to the same functionality on Area|Code & Unit Test|http://almmashups.serena.com/tmtrack/tmtrack.dll?IssuePage&RecordId=11531&Template=view&TableId=1000

depunits.txt

# 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

stages.txt

# list of mocked stages should be defined here

# use the following format

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

ST0001|SIT|QLARIUS:Q1S,QLARIUS:Q2S,QLARIUS:RLM_TEST

areas.txt

# 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