Browse Prior Art Database

Method and System for advanaced transformation to migrate source repository objects into target configuration management repository using simple, powerful and extensible domain specific language rule.

IP.com Disclosure Number: IPCOM000247761D
Publication Date: 2016-Oct-06
Document File: 9 page(s) / 53K

Publishing Venue

The IP.com Prior Art Database

Abstract

Movement of large repository source that takes large amount of time generally involves a lot of manual intervention both at the source repository level and the target repository into which it gets migrated. The idea is to propose a mechanism which facilitates in providing advanced transformation capabilities which are configurable and extendable to support the movement of large repositories from source configuration management system into the target configuration management system. In order to support the advanced transformation there needs to be a mechanism which facilitates for configuring and running simple and powerful rules that are expressive and are extensible. The rule specification should also allow for mentioning a combinational rule and also allow to specify them in a DSL(domain specific language), a scripting language such as Groovy and also a programming language such as Java.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

Page 01 of 9

Method and System for advanaced transformation to migrate source repository objects into target configuration management repository using simple , powerful and extensible domain specific language rule.

Movement of large repository source that takes large amount of time generally involves a lot of manual intervention both at the source repository level and the target repository into which it gets migrated. The idea is to propose a mechanism which facilitates in providing advanced transformation capabilities which are configurable and extendable to support the movement of large repositories from source configuration management system into the target configuration management system.

In order to support the advanced transformation there needs to be a mechanism which facilitates for configuring and running simple and powerful rules that are expressive and are extensible. The rule specification should also allow for mentioning a combinational rule and also allow to specify them in a DSL(domain specific language), a scripting language such as Groovy and also a programming language such as Java.

Source repository migration is one of the important aspects in order to move from one source management system into another source management system. The transformation of source before moving to destination repository is generally achieved using transformational rules. The existing rules supported by the source control tools, lack the expressive capabilities and are generally limited to a specified functionalities which can not be extended and also there is not even support for combinational rules.

Transformation Rules Syntax:

The proposed mapping rule to perform the required transformation will include a list of individual rules and each rule will be of the form:

WHEN conditionaction


Throughout this report, keywords such as WHEN in the above example are shown in upper case for clarity, but the intention during parsing is to accept keywords in any case, including title case. In other words, any of 'WHEN, 'when', or 'When' would be accepted.

The transformation rules file may also contain one occurrence of the pseudo-rule INCLUDE_AUTO_RULES. This pseudo-rule is replaced by the rules generated from the transformation patterns on the types in the database.

A condition is either a built-in DSL condition, or a fragment of Groovy code in braces. If Groovy code is given, it will be evaluated to yield a Boolean. Note that almost all Groovy expressions can be evaluated to Boolean values - this is a feature called the Groovy Truth .

An action is either one or more built-in DSL actions, or a fragment of Groovy code in braces. If Groovy code is given, it will be evaluated, presumably with desired side effects. These effects will be obtained through calls to the defined transformation API, with some extensions to access the specific transformation rule and related object.

Note that the entire condition is either DSL or Groovy, and not a mix of the two. The s...