In (specially) mainframe development environment, there are situations in which duplicate element names can be problematic. And from time to time I get helping customers migrate to Rational Team Concert, I find them asking of a way of ensuring this source elements names uniqueness in SCM can be enforced. In this post I am going to show an advisor for such enforcement, and talk about some restrictions to the approach.
I have recently been working on writing a custom service to automate some computed information retrieval from an RTC Server. That service I wanted it to have a configuration property that could be set/modified using the Advanced Properties page (https://<yourServerURI>/ccm/admin). In that process I faced a “dummy” issue that made me waste some precious time, so I wanted to share here my experience.
This post is meant to be a really short one, with the idea of providing a tip based on my experience.
Note: if this a kind of custom element you may need in your deployment but you don’t know where to start, I advice you to firstly take a look at Hello Jazz — How to write a simple Jazz component at jazz.net.
From some time I wanted to try the new Project Process Sharing feature called “Fine-grained Customization of Configuration Data”. This feature provides great flexibility in how process consuming project areas can tailor the inherited process configuration data section. The feature main documentation wiki page can be found here.
While more customization possibilities will come in the future, the supported customizations in RTC 4.0.1 documented in the wiki page supported customizations section, already provide a set of cases I usually find working with customers. In this post I am going to model a simple typical scenario and, based on the Delta Configuration Examples page, document my steps.
Project Process Sharing is a great feature that allows an organization to keep a consistent process specification across different projects. It leverages getting the process definition from a central managed project area, and to pick up process changes automatically. This feature for standardization still allows individual projects to perform some customization of the inherited process to accommodate individual process particularities. A good introductory tutorial can be found here.
It’s been several months of hard work … my colleague Robin Yehle Bobbitt and I are proud to announce the RTC V4.0 Enterprise Extensions Build Administration Workshop now available on jazz.net.
I have been recently working on extending the Rational Team Concert Bugzilla Importer functionality and I wanted to take some time to blog about it. Rational Team Concert provides an Import wizard to migrate Bugzilla Bug Reports to RTC. The details of such feature are described in this jazz.net article and this InfoCenter topic.
Update Feb 11 2013: I have updated the shared code to be able to ignore the Bugzilla bugs’ attachments.
The post content is the original one but you will find in the wizard the option to ignore the import of attachments, which may be useful when you are migrating old bugs information for traceability but you don’t want to carry all the attached files to your RTC database.
From some time ago I wanted to post a chunk of code to enable to launch a build as a result of a deliver operation. I have found myself in some situations in which this kind of automation has been asked, and I wanted to play a bit wit the SCM part of RTC SDK, so in this post I want to publish some code sample that I hope will be useful for people having this or a similar need.
I have been recently working with a customer in helping him understand the RTC SCM model and the typical operations that a developer will perform like checking in changes, associating a work item to a change set, delivering and accepting changes. The review of these operations were on the context of a simple team stream sharing scenario: