It's all about the answers!

Ask a question

Sharing Attributes among Artifact Types - Migration Issue from RRC 2.x to 3.x


Saran Kathirvelu (36911) | asked Jun 05 '12, 11:55 a.m.
I have migrated from RRC version 2.x to 3.x .  As we know, In 2.x, Artifact Attributes cannot be shared among Artifact Types. But in the latest 3.x, Attributes can be shared among Artifact Types. My Question is after the migration how do i share my Attributes among Types without breaking the existing values set for the Attributes in Artifacts/Requirements migrated from 2.x . This would really help us in efficiently managing/using Attributes and also drastically improve the filtering and searching capabilities.

Note: I know how to share artifact attributes among artifact types in 3.x

For Example:
Following is one of the Artifact Type/Artifact Attribute/Attribute Data Type combination migrated from 2.x :
Artifact Type = "Functional" 
Artifact Attribute  = "Functional/Tracking Number"
Attribute Data Type = "Functional/Tracking Number/Tracking Number"   (Data Type = Integer)

Now I have changed the above combination as follows in 3.x to share the Artifact Attribute with other Artifact Types:
Artifact Type = "Functional" 
*Artifact Attribute  = "Tracking Number"   (Data Type = Integer)

My Question is --  If the original Requirement/Artifact migrated from 2.x had a value of "1234" for the "Functional/Tracking Number" Artifact Attribute, Is there a way to automatically transfer the 2.x value of "1234" to the newly created *Artifact Attribute "Tracking Number"  in 3.x ?  

I'm surprised that the RRC Development Team didn't implement this simple concept of sharing attributes in the first place for earlier versions like 2.x. It makes life difficult for users like us who want to use this product efficiently.


One answer



permanent link
Alastair Stuart (6) | answered Jun 13 '12, 8:33 a.m.
JAZZ DEVELOPER
There is no out-of-the-box solution for performing batch-style refactoring, but the RM OSLC interface would allow you to do some custom refactoring.  see: http://open-services.net/bin/view/Main/RmHome

Neither is there a blueprint for doing this, but the API provides the ability to read types - despite them being called 'shapes' in OSLC - and the ability to read-write resources which provide the basic tools for performing refactoring of arbitrary complexity.  i.e. it would be the responsibility of the implementor to manage the mappings from the undesirable to the desirable shape of the type system.

It is worth noting that OSLC only exposes the ability to affect the 'head' of the revision history.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.