Project

General

Profile

Feature #1529

move customer_specific_conversion.rules into p2j/rules/conversion/ and improve/refactor it into a cleaner set of tools

Added by Greg Shah almost 12 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
09/10/2012
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
version_reported:
version_resolved:

ca_upd20121012a.zip - First version of P2J changes. (5.33 KB) Greg Shah, 10/29/2012 12:24 PM

ca_upd20121012b.zip - First version of MAJIC changes. (14.1 KB) Greg Shah, 10/29/2012 12:24 PM

ca_upd20121016a.zip - Updated P2J changes. (5.59 KB) Greg Shah, 10/29/2012 12:24 PM

ca_upd20121016b.zip - Updated MAJIC changes. (14.3 KB) Greg Shah, 10/29/2012 12:24 PM

ca_upd20121016a.zip (5.58 KB) Constantin Asofiei, 11/01/2012 12:26 PM

History

#1 Updated by Greg Shah almost 12 years ago

This rule set was incorrectly placed in TIMCO's pattern/ directory. It has nothing TIMCO-specific in it. Please move it into the standard location and change its name to "standard_customer_specific_tools.rules". That will make the purpose more obvious.

Then you will have to change the core_conversion.xml to load it (non-optionally). You can leave the customer_specific_conversion.rules as an optional rule-set. I suspect it should be optionally loaded before the standard_customer_specific_tools.rules. Please add a feature to standard_customer_specific_tools.rules that will bypass processing for a customer_specific node if it is marked with a particular boolean annotation named "handled". That will allow the customer_specific_conversion.rules to override the behavior in standard_customer_specific_tools.rules since it can process something however it wants and then it can mark the node with that annotation, causing standard_customer_specific_tools.rules to bypass the node.

Finally, please review the standard "tools" currently provided by this rule-set. If there are any obvious changes or improvements that should be made, please make the changes. It is OK to break the current "contract" of the tools so long as you fix it up in the TIMCO customer_specific_annotations_prep.rules, such that the result is the same.

The overall objective is to ensure that a standard set of tools is always there in the conversion environment AND that a given project can still make overrides as needed.

#2 Updated by Constantin Asofiei almost 12 years ago

  • Status changed from New to WIP

#3 Updated by Constantin Asofiei over 11 years ago

Sent final updates for review (for both P2J and TIMCO projects). The other_customization.odt and managing_changes.odt were updated, the new info was bracketed in [CA] ... [/CA] tags.

#4 Updated by Constantin Asofiei over 11 years ago

  • Status changed from WIP to Review

#5 Updated by Greg Shah over 11 years ago

#6 Updated by Greg Shah over 11 years ago

  • Status changed from Review to Test

I have reviewed the changes and they look good. Go ahead and apply these to staging, run conversion and get them tested. I presume that there is no difference in the converted code. But to be safe, please go through the whole process.

Well done!

#7 Updated by Greg Shah over 11 years ago

  • Target version set to Milestone 2

#8 Updated by Constantin Asofiei over 11 years ago

This does not affect MAJIC. Regression testing has passed. I've made a small change to standard_customer_specific_tools.rules - the "constructor" annotation is checked for existence, and not for value (to be in sync with the others) - the getNoteBoolean("constructor") was changed to isNote("constructor").

Applied to CVS.

#9 Updated by Greg Shah over 11 years ago

  • % Done changed from 0 to 100
  • Status changed from Test to Closed

#10 Updated by Greg Shah over 7 years ago

  • Target version deleted (Milestone 2)

Also available in: Atom PDF