It's all about the answers!

Ask a question

Component metadata


David Samuelsson (2161) | asked May 15 '08, 8:38 a.m.
is there any plans to be able to add meta data regarding the components that's stored in Jazz VCS? Then also being able to query upon that meta data. Or is there an extension point that can be used to add custom meta data regarding components?

Clearcase can do some of this but not good enough, just out of experience on issues we have seen here are some pointers.

* What components are active/dead?
* ability to archive/deprecate an component
* Who owns a component?
* component description (what does it do?)
* component paths, i.e if it's stored in clearcase i.e VOB:\xxx\componentname
* component security restrictions, i.e not allowed to be accessed except team x and y.
* Component version existence in different projects
* Component version existence in different baselines in different projects.
* Component relationship to other components i.e depending or dependant (usually in modelling but an dependency would be very good to have database driven)
* ability to see all breakdown of a program of projects, i.e program x consists of 10 projects, for project y in program x these 200 baselines exist. For this particular z baseline in project y in program z we have these 300 components. This component called xyz has 50 versions.

then you can imagine all the searches you can ask, for example this version of component xyz is included in these 20 baselines in these 10 projects in these programs.

* ability to add custom meta data regarding components
* ability to request an component, for example from architecture to get an approval to create it.

Thinking of the total component life cycle would be a good idea i think.

thoughts, comments?
/Dave

2 answers



permanent link
Adrian Grindrod (611) | answered May 29 '08, 7:41 a.m.
Dave,

I have a similar type of desire, but from a slightly different perspective.

One of the things I like about ClearQuest is the ability to modify the schema to create things (records) that are not necessarily "Work Items" and then associate them to the "Work Item" itself. What this does, is it allows you to create a "database" of information associated with the "work item".

To apply this in your context then, I could see that this concept could be re-used whereby these customizable non-work items are instantiated and associated to the components. Hence create Component Metadata in the way that you want. From then you query on this set of data items and their associated components. Obviously it would make sense then that the Community/Jazz Dev Team could provide reusable/customizable (and tested?) data schemas to save everyone reinventing the wheel.

Does this concept work for you?

If so, question for the Community/Dev Team, can this be done?

/Adrian

is there any plans to be able to add meta data regarding the components that's stored in Jazz VCS? Then also being able to query upon that meta data. Or is there an extension point that can be used to add custom meta data regarding components?

Clearcase can do some of this but not good enough, just out of experience on issues we have seen here are some pointers.

* What components are active/dead?
* ability to archive/deprecate an component
* Who owns a component?
* component description (what does it do?)
* component paths, i.e if it's stored in clearcase i.e VOB:\*\componentname
* component security restrictions, i.e not allowed to be accessed except team x and y.
* Component version existence in different projects
* Component version existence in different baselines in different projects.
* Component relationship to other components i.e depending or dependant (usually in modelling but an dependency would be very good to have database driven)
* ability to see all breakdown of a program of projects, i.e program x consists of 10 projects, for project y in program x these 200 baselines exist. For this particular z baseline in project y in program z we have these 300 components. This component called xyz has 50 versions.

then you can imagine all the searches you can ask, for example this version of component xyz is included in these 20 baselines in these 10 projects in these programs.

* ability to add custom meta data regarding components
* ability to request an component, for example from architecture to get an approval to create it.

Thinking of the total component life cycle would be a good idea i think.

thoughts, comments?
/Dave

permanent link
David Samuelsson (2161) | answered May 30 '08, 10:00 a.m.
we are actually infact doing that internally right now, to use CQ in a slight other way then it was intended for.

/Dave

Your answer


Register or to post your answer.