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.
This is a really short post to share some information I found after being continuosly hit by “JVM terminated. Exit code=1″ in various Eclipse based products: RSA, RDz and RTC.
Note: bear in mind I work in Linux, and the information I am to share here just applies to that OS. Windows users, seems like you can feel safe this time :p
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.
Work Item based Promotion allows you to move your changes related to a certain work item in your streams hierarchy. At the same time, Rational Team Concert allows a great flexibility to “move” your changes between work items, so developers can report their work or decide which changes better represent their tasks work. However, when it comes to work items promotion, there are times where this flexibility can lead you to undesired scenarios.
One of the coolest features of CLM 4.0.4 (and personally most waited), that I wanted to blog about is the Simulation Dependency Build. This feature allows you, basically, to run a Dependency Build without physically building anything, but generating all the metadata involved in these builds.
The use of Personal Builds allow a developer to verify if their checked in changes build successfully without impacting the team build, or waiting for a deliver-build cycle. In this forum post I want to discuss how to configure your Rational Team Concert deployment to allow the parallelism of personal builds by your developers.
At this point you may be already be familiar with the Promotion and Packaging Enterprise Extensions features, and how you can use them in a work item basis. You can specify concrete work items to be promoted or packaged, therefore associated changes will be the ones to consider in these processes. This offers great fine grain control of how your changes are to progress in your defined development flow, which is to sum with all the goods that managing change sets with work items offer (traceability, process control, …).
In this post, however, I want to discuss the case of dependencies impact and their management: when files get rebuild because a source they depend on has been modified. I will provide a custom Ant task as sample approach for automatically linking those files rebuilt to a work item to incorporate them (and their outputs) in the development flow. In the last part of this post I want to also introduce some new features improvements coming in RTC.