It has been a while since my last post. It hasn’t been because of lack of ideas, rather time, although the blog has been bugging me in the back of my mind for attention for quite some time. So here we go … for this come back I have picked an always interesting topic, to force some rules in your SCM.
I wanted to talk about one aspect of managing change sets in Rational Team Concert. Tools like RTC and Rational Developer for z Systems come in hand with the cultural and practices changes in the umbrella of Enterprise Modernization, but let’s face it, there are certain challenges that come into play in discussions with customers quite commonly and will take some time to leave … if ever (languages used and platform peculiarities play their part as well).
I guess any user of Rational Team Concert Enterprise Extensions is familiar with the packaging feature (see Packaging and deploying with Enterprise Extensions otherwise). This packaging feature, based on the location specified in its definition, stores the package it generates for a later deployment. The package can additionally be added to the packaging result Downloads tab with the following flag:
While the package result provides a great insight of what has been packaged in the “Package Summary” tab and the “Package Summary Work Item” that creates; what if I want to manually inspect the contents of the package? Continue reading
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.
The past days, while I was trying the configuration of a deployment of the Build System Toolkit and the Build Agent (based on version 4.0.4), in a test system using the Money that Matters sample, I faced the following error running a build:
PTY allocated pseudo-tty *PtyPipe
EXEC Unable to set working directory to '"/u/<userX>"' (111).
I want to blog about this error and its resolution, taking the opportunity meanwhile to provide links to important configuration information.