The RTC Extensions Workshop has been updated for EWM 7.0.x

I am very passionate about the RTC Extensions Workshop as you might be able to tell from the content of this blog. Performing it with EWM 7.0.x provided several challenges. It became apparent that an update to the workshop would be beneficial.

I spent a considerable amount of time in the past two months to update the workshop. As a summary the following items where addressed:

1. Since the CCM server is shipped with WebSphere liberty profile, configuring the server for debugging needed to be changed. The old way to configure the server still worked in the 6.0.x versions, so it went unnoticed. With EWM 7.0.1 this is no longer the case and the workshop was updated to address this.
2. The advanced capabilities introduced in the EWM SCM system in the 6.x and later caused a deviation of the screen shots showing the pending changes. The workshop setup tool was slightly changed to fix this.
3. The workshop setup tool and its shell script has been tested with Linux and MAC OS.
4. I wanted to add a section to Lab 1, explaining how to setup the existing Eclipse client/server development workspaces to better support development and debugging of the Plain Java Client Libraries forever. The new last optional section addresses this. For this reason Lab 1 of the workshop is a must for anyone intending to create Java based automation or extensions to RTC/EWM.
5. I had an errata list with a number of small issues, typos, naming inconsistencies and the like that were fixed. During reviews a bunch more showed up and were fixed.
6. A colleague ran the workshop on his MAC, so this works. Use whatever is available for MAC like Eclipse and where this is not specifically available, use the Linux versions.

The RTC Extensions Workshop has been published with an additional section for the new EWM versions and is now available for download. I will update recent posts around the workshop in the next few days.

As always, I hope that this blog post helps the users in the Jazz Community.

Advertisement

EWM Extensions Workshop remote debugging in 7.0.x

As explained in Issues with the EWM/RTC Extensions workshop in 7.0.x versions, I experienced issues with configuring the EWM Development server for remote debugging. The first EWM version I experienced this, is 7.0.1.

As mitigation I suggested to replace the JRE with an earlier one, or one that works. Unfortunately, this does not look sustainable. I have tried downloading the newest IBM Java SDK and the issue still happens.

I have looked a little bit deeper into it and discovered that the server.startup script provides a debug option. Using this option allows remote debugging the EWM server. I am looking into an update to the RTC/EWM Extensions Workshop for 7.0.x. until this is available here a procedure how to follow the workshop for 7.0.x versions.

Update for the Extensions Workshop now available

All the issues have been addressed in an update to the RTC Extensions Workshop for the 7.0.x and later versions. This should address all the issues.

Lab 1.2 – Do not add debug arguments.

In Lab 1.2, do not add the following lines to the server.startup script, remove these lines:

set JAVA_OPTS=%JAVA_OPTS% -Xdebug
set JAVA_OPTS=%JAVA_OPTS% -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=3388

Scroll to the bottom of the server.startup script and inspect the statements behind setting the JAVA_OPTS. Note that there are an action and an option supported.

Special parameters supported for starting Liberty Profile

Start server for remote debugging

The action -debug can be used to start the Liberty Profile Server in debug mode. When following the workshop, continue to Lab 1.5.

Follow the lab until 1.5__32 Add the following steps:

Open a console/cmd window and change directory into the server folder containing the server.startup script. Stop the development server by running server.shutdown.

>server.shutdown

Wait until the server is successfully stopped. Start the development server by running the following command.

>server.startup -debug

Note that the server does not start, it suspends listening for a remote connection on a dt_socket/port. The default socket/port address is 8000.

Server waits in debug console

The server will not continue starting unless a remote connection is opened on that port.

Connect Eclipse as remote debugger

Follow the workshop and open the [RTCExt] Debug Running Liberty Profile launch configuration. This launch is used to connect to a remote Java application. In our case the application is the RTS/EWM development server waiting on socket/port 8000.

Change the port in the launch to 8000 then click Apply and Debug.

Change debug port to 8000 apply and start debugging.

Switch to the command prompt. It takes a while and the server continues to start. Wait for the server application to successfully start.

Continue with the workshop and remote debug the server.

When disconnecting from the remote Java application, the RTC development server will show again, that it waits for a remote connection.

Reprovision the Jazz applications

The option -clean can be used to force to re-provision the Jazz Applications installed on the Liberty Profile server. This is necessary to force rereading custom server extensions during deployment of these extensions. The option can also used together with the -debug action.

Summary

Following the solution described above, allows to successfully perform the Lab 1.5 of the Rational Team Concert Extensions Workshop. I am currently trying to find out if there

• Is an option to change the default port for this option
• Is an option to avoid suspending the server startup until the remote debugger connection is initially done

I will update the workshop and publish the changes. I have already done several other changes to adjust the workshop for the newer EWM/RTC versions.

As always, I hope that the blog posts here help users in the Jazz community.

RTC Extensions Workshop – How to fix SSL protocol errors preventing connection to Jetty Debug server

Since some time now I started to run into a blocking issue with the Extensions workshop. I was not able to find a solution so far. Today a colleague saw the same and asked for help. Here what I found.

Problem: the browser prevents connecting to the Jetty server

When launching the Jetty Debug server, everything seems to be fine. You can even connect with an Eclipse client to the server. However, if you try to follow the description in the Extensions Workshop and you try to connect with a browser to https://localhost:7443/jazz/admin you see a screen like the one below.

In Chrome the error claims

This site can’t provide a secure connection localhost sent an invalid response.

Try running Windows Network Diagnostics.

ERR_SSL_PROTOCOL_ERROR

Firefox is even more alarming and says

Secure Connection Failed

An error occurred during a connection to localhost:7443. Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

Please contact the website owners to inform them of this problem.

Learn more…

Report errors like this to help Mozilla identify and block malicious sites

Edge complains

Can’t connect securely to this page

This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.

Try this:

Go back to the last page

It looks like the usual SSL issue with the standard certificate, but it actually is not. It does not allow you to proceed and add an exception to connect to the web site.

You are basically stuck.

I had the same issue yesterday with 6.0.5 and 6.0.6 and I knew it was working very recently – when I moved to my new laptop. I searched the internet and was not really sure about a solution still. The answers pointed at version issues and certification mismatches. So I decided to switch the Eclipse environment to a current JDK and that solved the problem. I have tried it with RTC 6.0.5 and 6.0.6 but I am pretty sure it would work with other versions as well.

Please note that the Extensions workshop suggests to use the same JDK the Server uses. I think since Browsers have recently increased their security measures, this is no longer true.

Solution

Here how to fix the problem.

• Download and install a recent Java JDK/JRE that is compatible with the version of the RTC SDK you are working with.
  • 6.0.6 is compatible with Java 1.8
  • I use a JDK because there are other development tools that require a JDK
• Open the Eclipse server development workspace
• Open Window>preferences
• Type JRE and navigate to Java>Installed JREs
  • Add the new JDK/JRE
  • Select the JDK/JRE as active click Apply and Close
  • Navigate to Java>Installed JREs>Execution Environments
  • Select the Execution Environment with the matching version
  • Select the new JDK/JRE as active click Apply and Close
• Launch the Jetty debug server

Now try to login to https://localhost:7443/jazz/admin again. You still get an error, however the browser provides the Advanced link to continue connection to the site.

The different browsers display it different, but the concept is the same for all of them.

Summary

Recent increases of browser security checks and invalidation of certificates requires to update to recent versions of the Java JDK/JRE to be used with the Extensions workshop. As always I hope that this helps people out there.

The RTC SDK is about to change in 6.0.3

Since some time now, the RTC and Jazz Development teams are in discussion how to cope with the version compatibility requirements driven by Eclipse clients and the server API. In RTC 6.0.3 the SDK is about to be split into separate SDK’s for the Eclipse client and the Server. This will impact how the development environment needs to be set up and how extensions are developed. I will try to share a summary of what to expect here. I have so far only been able to experiment with development builds, there has not been an official release of the SDK for 6.0.3 yet.

Download the new workshop

Update * the new Extensions Workshop is finished for a while now. it can be found at the original Rational Team Concert Extensions Workshop location.

Why splitting the SDK?

The RTC Clients have been based on Eclipse 3.6 for a considerable amount of time now. This has been the case for the Jazz Servers as well. However, there is pressure on the server infrastructure for the need to support Eclipse 4.4.x and higher. On the other hand there are client applications that RTC needs to integrate with, that are lagging behind in adoption of new Eclipse versions.

As described in What API’s are Available for RTC and What Can You Extend? the RTC SDK currently contains the RTC Server API, the RTC Common API and the RTC Client API in one delivery. The RTC Common API is part of the RTC Server API as well as the RTC Client API. This is a potential problem when shipping the SDK and trying to keep the Server compatible to Eclipse 4.4.2 and above and being compatible with Eclipse 3.6 clients. As it looks, the RTC SDK will be split into two parts.

1. A RTC Server SDK bundling the RTC Server API and the RTC Common API compatible with Eclipse 4.4.x and higher
2. A RTC Client SDK bundling the RTC Client API and the RTC Common API compatible with Eclipse 3.6.x and higher

Impact of splitting the SDK

The split has various impacts on how extension development will now work. Please find below a short summary of changes that I have found necessary to perform the workshop.

Changes to section: 1.1 Download and Unzip the Required Files from jazz.net

The Server SDK Target Platform now requires an Eclipse 4.4.2 or higher. You can download the base Eclipse 4.4.2 client here. For example download the version Eclipse IDE for Java EE Developers. Install the client similar to described in the workshop. Then download the RTC Eclipse Client p2 install package and install this into your Eclipse 4.4.2.

In the Feature Based Launches download the new launcher442.zip. Unzip the zip file, browse to the enclosed JAR file and copy that into the dropins folder in the Eclipse client.

You might want to consider to do the following changes to the eclipse.ini file.

• Add a section -vm with an additional line for the java virtual machine to use. If you run Eclipse with a different JVM, e.g. from Oracle, consider to specify a JRE or JDK that is compatible with the one that ships with RTC. This vm would also be used in the workspace setup section.
• Add -showLocation in the org.eclipse.platform section; this shows the Eclipse workspace path in the upper border of the Eclipse client as below

  

  This makes it possible to actually work with multiple workspaces and knowing which an Eclipse instance is responsible for.

• A vmargs argument -Duser.language=en to make sure you get a consistent language in the menus if you want.

The image below shows the changes in my case

Changes to section: 1.2 Setup for Development

Once the SDK is split into two parts the Rational Team Concert Extensions Workshop can no longer be performed using just one Eclipse Workspace. An SDK is set up as a Target Platform in the Plug-in Development section. Since the SDK’s are now split, it is necessary to have two target platforms. Since it is not possible to have more than one Target platform active in one Eclipse workspace it is not possible to launch a server for debugging while running an Eclipse client from the same workspace.

The RTC Extensions workshop will have to be changed to set up two separate workspaces.

• One workspace will have to be set up with the RTC Server SDK as active Target Platform, for example using the path: C:\RTC603Dev\Workspaces\Dev1\Server
• The other  workspace will have to be set up with the RTC Client SDK as active Target Platform, for example using the path: C:\RTC603Dev\Workspaces\Dev1\Client

Both workspaces will require to be set up as described in the RTC Extensions workshop document in section 1.2 Setup for Development.However, you will set up different target platforms in this step. Using the Server SDK for the server development workshop and the Client SDK for the Client development workspace.

Please note, it is a good idea to configure Eclipse to use an external browser as well in this step.

Changes to section: 1.3 Setup the RTC Tomcat Server

I am modifying the WorkshopSetup tool and data to setup the RTC project named RTC Extension Workshop to support an easier setup for the two workspaces. Basically two separate RTC Repository workspaces will be available. One will provide the launch, the configurations and the components needed to develop the RTC Eclipse server extension part of the workshop. The other one will provide the launch and the components needed to develop the RTC Eclipse client extension part of the workshop.

As long as this is not yet available it is possible to start with the existing setup tool and the related repository workspace and to load that into the two Eclipse workspaces. One workspace has to be set up with the RTC Client SDK will be used for development of the client part. The other with the RTC Server SDK set up is used to develop the server parts. When performing the workshop it will be necessary to work with the two workspaces and use one for all the server related tasks and the other one with the client related tasks. When Accepting changes into these workspaces it is necessary to understand what is part of the client and what is part of the server or what is shared. The image below shows what belongs to what.

• The parts colored in blue are only related to server development
• The parts colored in yellow are only related to client development
• The uncolored parts are related to client and server development

Make sure to keep in mind which parts of the code are relevant for what. As an example, the project net.jazz.rtcext.workitem.extensions.ide.ui will not compile in the server development workspace. Similarly the net.jazz.rtcext.workitem.extensions.service project will not compile in the client development workspace.

Changes to section: 1.4 Complete Setup of Your RTC Eclipse Client

After Loading the repository workspace you have the choice to split the information into a sever part and a client part. For example you can duplicate RTC Extension Workshop Configuration and create one that only contains the client launches. Or you keep everything as it is and basically close the project areas you don’t need and ignore launches not needed. This is the easiest approach until a new Extension Workshop is available.

The initial step of copying the files services.xml and scr.xml is only needed in the server workspace. So when copying and importing, copy the files services.xml and scr.xml from your server’s ccm application in the installs\JazzTeamServer\server\conf\ccm folder into the RTC Extension Workshop Configuration project into the folder conf/jazz in the server development workspace.

When importing the plugins and features import the following into the server workspace:

• com.ibm.team.common.tests.utils
• com.ibm.team.jazz.foundation.server.licenses.enterprise-ea (or com.ibm.team.licensing.product.clm)
• com.ibm.team.licensing.product.rtc-standalone

When importing the plugins and features import the following into the client workspace:

• com.ibm.team.rtc.client.feature

Other considerations

As already mentioned, make sure to keep track which workspace you are working in and keep in mind that the server development part will not work in the client development workspace and vice versa.

Just Starting With Extending RTC?

If you just get started with extending Rational Team Concert, or create API based automation, start with the post Learning To Fly: Getting Started with the RTC Java API’s and follow the linked resources.

You should be able to use the following code in this environment and get your own automation or extension working.

Summary

We have major changes coming up in the RTC Extension development area. The RTC Extension workshop needs to be adjusted and parts of the workshop lab needs to be reorganized and rewritten. This post explains what to consider for experienced users. Once there is an update to the Extension workshop lab material this post will be updated.

As always, I hope this helps users out there and saves them some time.

Running the RTC Extensions Workshop With RTC 6.0.1

RTC version 6.0.1 is available since end of December 2015. I ran a test to find out if the Rational Team Concert Extensions Workshop still works with RTC 6.0.1. This is what I found.

The version 6.0.1 does not ship Tomcat any more. The Rational Team Concert Extensions Workshop explains how to debug deployed extensions on a Tomcat test server. How does this change the workshop?

Important note: Debugging on Tomcat is only presented as an option, it can be useful if an extension has been fully developed on Jetty, but shows a different behavior on a real environment. Using this technique to develop an extension step by step is not a suggested procedure, instead using Jetty is the preferred way. From this perspective, Section 1.5 in the lab is unimportant for the rest of the workshop and this step could actually be skipped.

Summary

By installing the default values and basically choosing WAS Liberty Profile the workshop works. Basically Tomcat is replaced with WAS Liberty Profile and everything should work as expected. Due to the changes over time, some small adjustments are needed or useful. these adjustments can be found below.

Update

Please see the update for changing the development application server configuration to enable debugging.

Update the issue is fixed: Please note that currently The SDK for RTC6.0.2 has a defect that makes it impossible to be used. See 390811: RTC SDK breaks Extension workshop with missing feature com.ibm.team.rtc.update.site.content.rtc.feature. Use an earlier version of the SDK to develop for now.

Install and Setup Changes

Here some changes that make the workshop more effective. They are described in the workshop in several notes, here a more explicit description.

Section 1.1 Download and Unzip the Required Files from jazz.net

The easiest way to do the Rational Team Concert Extensions Workshop I have found is not to use the Web installer, but to use the ZIP version of RTC.This requires sone minor changes to the sections 1.1. and 1.2 as described below.

You can use the Web Installer, as well as the IBM Installation Manager. If using the Web Installer the changes for 6.0.1 begin in Section 1.3 Setup the RTC Tomcat Server. If using the Installation manager, make sure to install into the folder as described in the workshop.

 1.1__1. Download the product installation files.

In step _b: As alternative, download the ZIP version of RTC named “Jazz Team Server and the CCM Application, and Trial licenses for Rational Team Concert”.

Follow the rest of the steps of 1.1_1 and 1.1_2 as described.

If you want to follow the steps from the Rational Team Concert Extensions Workshop and use the web installer, or a the IBM Installation Manager install, make sure to install

 1.1__3. Install the RTC Eclipse client and a test server.

In step _b: To install the zip version of RTC, extract the zip file JTS-CCM-keys-Win64_6.0.1.zip you downloaded for “Jazz Team Server and the CCM Application, and Trial licenses for Rational Team Concert” to the folder:

C:\RTC601Dev\installs\JazzTeamServer

Continue with step _h Unzip the Client for Eclipse IDE zip file

Section 1.3 Setup the RTC Tomcat Server

Instead of Tomcat RTC and CLM 6.0.x bundle WAS Liberty Profile.

 1.1__3. Setup to run the server in debug mode

On windows I have followed the original descriptions in the Extesnsions workshop and added the Java options to the server.startup.bat and it worked for me.

However Lewis Tsao reported in the comments below that on Linux there are changes. He reports the server just dies if he uses suggested lines. He found the article https://jazz.net/wiki/bin/view/Deployment/EnableLibertyRTCServerDebugMode. Based on this, even on Windows it might be worth exploring this and follow the link above. For mode details look at his comments below.

Note that

• For 6.0.1 the server should be started as “./server.startup -debug” or modify “DEBUG=false” in server.startup to “DEBUG=true”
• For 6.0.2 the server should be startd as “./server.startup debug”

1.1.__14_b. Open And Review the WorkshopSetup.bat file

The windows version of this file has sometimes problems with some Java versions, because the parameter order is kind of skewed. During development of the tool, this never came up. It will be fixed in a newer version.

Move the parameter -jar in front of the parameter WorkshopSetup.jar

Instead of

the batch file should look like this:

Follow the other suggestions to consider and change the file if needed and perform the rest of the steps as described.

When running the WorkshopSetup command I have very seldom seen errors, one I have seen today was maybe because of the server performance. If this happens, try running the WorkshopSetup again.

Section 1.4 Complete Setup of Your RTC Eclipse Client

For an unknown reason, the project was not initialized. Right click the project in the Team Artifacts view and click initialize to finish the project setup, if this happens.

Section 1.5 Test connecting the Eclipse debugger to Tomcat

If the changes to the server.startup.bat in section 1.3 where successfully performed, this section works the same way with the server deployed on WAS Liberty Profile.

Section 1.6 Test the Jetty Based Server Launch

The software needs more memory. In step

1.6__25__b.

change the memory available for the [RTCExt] Create RTC Test Database launch. The original setting is -Xmx256. With this setting I got a memory error in the JUnit test that creates the development time repository database.

Change the memory setting to -Xmx512 as shown below.

Section 1.7 Test the RTC Eclipse Client Launch

In step 1.7.__31.__b.__ii.

The Launch shows a missing bundle.

This missing bundle does however not prevent you from running the launch and as far as I can tell at this point in time, the workshop is still working. You can remove the missing bundle as well.

The rest of the workshop should work as desired.

Related Posts

• Running the RTC Extensions Workshop With RTC 6.0
  
• Unable to Connect to the Jetty Server Using Current Browsers Due to SSL Error
  
• Extending RTC Versions Lower Than 6.x
  
• Chrome Does Not Work With RTC Debug Server on Jetty
  
• Running The RTC 4.x Extensions Workshop With RTC 5.0.x
  
• RTC Extension Workshop Overhaul
  

Summary

The  Rational Team Concert Extensions Workshop still works for version RTC 6.0.1. I will however try to find some time to do an overhaul for RTC 6.0.2.

Unable to Connect to the Jetty Server Using Current Browsers Due to SSL Error Extending RTC Versions Lower Than 6.x

Attempting to connect to my Jetty server to debug a new RTC Extension I was working on in RTC 4.0.1, failed with an SSL error with all my current Browsers, Chrome and Firefox without being able to find a workaround in the browsers. How to work around that issue?

This problem only occurs when using the RTC SDK for RTC versions prior to RTC 6.x. It will affect all of these versions. It does not prevents performing the RTC Extensions Workshop since most of the tasks there can be done using the Eclipse UI. However, it impacts developing RTC Server extensions and test them properly, if it is necessary to use the Web UI because it is impossible to go into the web UI to test.

The problem I ran into is basically related to Chrome Does Not Work With RTC Debug Server on Jetty. However, it turns out that the work around described there does no longer work. Neither Tomcat nor Chrome allow to enable SSL V3 anymore showing errors like this in FireFox.

The messages contain text like

Unable to Connect Securely

Firefox cannot guarantee the safety of your data on localhost:7443 because it uses SSLv3, a broken security protocol.
Advanced info: ssl_error_unsupported_version

or

This webpage is not available

ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Hide details
A secure connection cannot be established because this site uses an unsupported protocol.

The only ways around I found so far are:

• Use the internal browser of the RTC Eclipse client of the version of RTC you are trying to extend
• Use a browser that does not block SSL such as Chromium in a version that allows the work around described in Chrome Does Not Work With RTC Debug Server on Jetty
  

You can download Chromium of various versions here. Version 44.0.2385.0 does still work for me and it does not update automatically.

The development team tracks the issue in Defect 354890. As long as there is no other solution, use the workarounds provided above. As soon as there are new news, I will try to provide the details.

Running the RTC Extensions Workshop With RTC 6.0

I ran a test to find out if the Rational Team Concert Extensions Workshop still works with RTC 6.0 using the RC1 build. This is what I found.

Update:

For RTC 6.0.1 see this post.

Summary

The RTC extensions workshop still runs with RTC 6.0 but you have to increase the memory available for the JUnit test to setup the development time repository database.

Detailed Findings

The workshop worked well, until in step 1.6 Test the Jetty Based Server Launch you create the development time repository database by running the JUnit test Launch.

The original setting is -Xmx256. With this setting I got a memory error in the JUnit test that creates the development time repository database.

Change the memory setting to -Xmx512 as shown below.

The second observation I made after successfully running the JUnit test was when I tried to launch the RTC Eclipse client in 1.7 Test the RTC Eclipse Client Launch. The Launch shows a missing bundle.

This missing bundle does however not prevent you from running the launch and as far as I can tell at this point in time, the workshop is still working.

Suggestion

Since the memory footprint seems to be increasing at least for the JUnit test, keep this in mind for the other launches. If you run into memory errors, increase the memory settings for your launches. You can find the parameters to consider in the server.startup.bat file.

Additional Information

A user in the Jazz.net Forum pointed out that there is a service error in the server Status summary. You can see it below.

This error has always been there, as far as I know. I think this is simply a test – the services seem to be just test services to test the error detection capability.

Finally

As always I hope this information helps users of the community in their work.

Chrome Does Not Work With RTC Debug Server on Jetty

Recently I tried to use Chrome with a RTC debug Server running on Jetty. I was unable to do so. Why does this happen and is there a work around?

Affected Versions

This problem only occurs when using the RTC SDK for RTC versions prior to RTC 6.x. The RTC 6.0 and later SDK’s are not affected as they enable TLS.

* Update * see Unable to Connect to the Jetty Server Using Current Browsers Due to SSL Error Extending RTC Versions Lower Than 6.x for newest developments and potential workarounds. This work around does no longer work for the newest versions of Chrome.

Symptoms

When I tried to navigate to the public URI https://localhost:7443/jazz/ of my debug server I got a message

This webpage is not available

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

See the screenshot below:

This webpage is not available ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I created Defect 354890 to get it addressed.

Root Cause And Work Around

As described in the defect above, it appears that Jetty uses SSL as a default protocol to talk to the browser. Chrome version 4 has disabled SSL due to defects in the older SSL implementations. This can basically also happen in other browsers soon.

To fix this, Jetty would have to be set to TLS as default. Although this seems to be the documented default for newer versions, the SDK does not seem to have that setting. I searched around and was also not able to find a way to force it.

It would be good if there was a way to set e.g. a System Property in the server launch configuration.

This work around I found on the net worked for me for Chrome v40:

• Open the URL chrome://flags
  
• Look for “Minimum SSL/TLS version supported.“
• Change from Default and choose SSLv3
• Click on the “Relaunch now” button

Open your public URI https://localhost:7443/jazz/ again. You will be redirected to a page “Your connection is not private“. Click on the “Advanced” link. Finally click on “Proceed to (unsafe)“.

Update

Chromium has the same problem. And the same fix.

Running The RTC 4.x Extensions Workshop With RTC 5.0.x

Since the new 5.0 version of Rational Team Concert and the CLM tools is out now, would the Rational Team Concert 4.x Extensions Workshop still work with this version?

The short answer is: Yes!

* Update * The error described below can be fixed. See the update in the description.

I just quickly tested if the Rational Team Concert 4.x Extensions Workshop works with the newest release 5.0 and I was able to successfully smoke test it. The same applies to newer versions of RTC.

To test if it still works, I performed Lab 1 completely. The new setup tool introduced recently ran like a charm and this was successful.

I then ran Lab 2 and finally Lab 5 with the complete code accepted. All labs worked as advertised. I would not expect any surprises in Lab 6 (except the normal issues when trying to deploy).

Observations

As there are some things that I notice that are different from the 4.x versions. I will summarize them here.

After setting up the SDK an error shows up in some of the project explorers. The error looks like below in the project explorer:

It seems to be an issue with the build path if one looks at the details:

I can’t remember having seen this in the past. Initially it only seems to come into the way when launching and does not seem to have any ill effects. Unfortunately it prevents refactoring operations.

To get around it, when launching, use this dialog to skip this issue:

If you check the ‘Always launch without asking’ option, be a ware that this could be problematic if your own code has errors as well.

* Update *

To get rid of this error you can delete the folder resources in the SDK folder installs/rtc-sdk/plugins/com.ibm.team.log4j.ui_1.2.0.v20140307_1622 after extracting the SDK.

In the other labs, the only thing that seemed to be different is that the Eclipse password secure storage is getting more persistent. You should probably provide a password, to avoid having to deal with it every time.

Summary

So you can run the Rational Team Concert 4.x Extensions Workshop with the current Rational Team concert version 5.0 and it is likely it will run also with later versions.

As always, I hope the code above helps someone out there with extending RTC.

RTC Extension Workshop Overhaul

It took a while, but the Rational Team Concert Extension Workshop overhaul was finally published on Jazz.net.

Just Starting With Extending RTC?

If you just get started with extending Rational Team Concert, or create API based automation, start with the post Learning To Fly: Getting Started with the RTC Java API’s and follow the linked resources.

You should be able to use the following code in this environment and get your own automation or extension working.

 What did change?

The new version of the workshop provides

• Compatibility to newer versions of RTC
• Compatibility to all RTC and CLM installation types
• Enhanced, simplified setup
• Small enhancements of the workshop to address minor changes in the SDK

The Rational Team Concert Extension Workshop is one of the most used workshops in the Jazz.net library. Unfortunately several changes in RTC since its design for RTC 3.0 caused a lot of problems for users. It needed a major change in how the required RTC repository is set up to make it easier to consume.

The main challenge was the set up of the RTC Development repository. The workshop was designed to use TAR database exports created with the repotools to import them and provide the repository as presented below. This repository contains the required development data which is accessible in a repository workspace and a stream with baselines and data.

This was a lot of manual effort, took time and worse, was not compatible across different versions of RTC. The old files could not be used with newer versions.

As described in this series of posts, the solution was to create the required project, stream and workspace using the Plain Java Client Libraries and upload the required source code to the stream.

The new workshop now uses a small Java Tool WorkshopSetup working with the Plain Java Client Libraries to create the project and to upload the content required to run the workshop. The tool can be downloaded with the Rational Team Concert Extension Workshop.

This allowed to completely remove the steps to import the repository content from the TAR files, which overwrite the repository you set up and rely on a specific setup of the servers done before to avoid conflicts. The removal of the repository exports also reduces the download size considerably.

Since the repository is no longer overwritten, there are no more potential issues with public URI’s and registered applications. It is also no longer necessary to recreate the index files after the import. All these steps where very manual, error prone and time consuming and the workshop is now much more consumable.

The server setup can now use the express setup and is less manual and much faster.

Since the repository is created during the server setup and not overwritten, the evaluation licenses are not expired. There are no license issues anymore. The step to upload the 10Free licenses could be skipped entirely and performed later, once the evaluation licenses expire, if one so desires.

The workshop workbook uses the Web install for RTC as default, but it also describes how to use the Plain ZIP version of RTC. I typically use the latter approach which has some advantages. One of it is, that Installation Manager is not involved and I can safely just delete the files, instead of doing an uninstall. This also works offline or with small bandwidth, if the files are already downloaded.

The WorkshopSetup tool can actually be run against any existing repository and it does not mater which other applications are installed. It should always be able to create the project and upload the content. If you want to start all over with the workshop, it would also be possible to run the WorkshopSetup tool multiple times (e.g. renaming the RTC Extensions Workshop project created for a prior run of the workshop).

The WorkshopSetup tool is started using a batch file or shell script. It will work if you follow the setup instructions. However, you can configure it, if needed. The parameters to configure it are highlighted in the image below.

There are no requirements on the administration user ID anymore, except that it is easier to follow the workshop workbook, if you use the proposed names. If you want to use a different ID, modify the user id and password entries in the workshop setup batch file. All other parameters can also be changed as desired.

Another benefit of the change of the install procedure is that all required data, the source code, licenses, the configuration and debug launch files are now available as exported Eclipse projects. These exports can be used even without having to run the workshop at all. E.g. the launches and configuration files are in the file WorkshopSetup/Data/Configuration/RTCEXTConfiguration.zip and can easily be imported into an Eclipse workspace.

The server launch configurations now contain all the bundles for the licenses that are used in the different ways to package RTC and CLM. Just import the ones from your setup and you are ready to go.

As long as there are no drastic changes to the Plain Java Client Library API the WorkshopSetup tool should work with any version of RTC in the future. It is no longer necessary to start with RTC 4.0 and then to upgrade the repository. I ran the tool with all available RTC 4.x versions up to 4.0.6 and it worked with no problems. The WorkshopSetup tool works also with RTC 3.0.x and it is safe to assume it will also work with upcoming versions of RTC.

* Update * It also works with 5.x.

In addition to these major changes, the launch configurations were tidied up to better map to the newer structures in RTC 4.x and later.

Some feedback from users was also used to make small changes in the labs to make things clearer, easier to follow and address small changes in the API since 4.0 in the text and screenshots.

Starting with Extensions and Automation?

If you just get started with creating extensions or automation for RTC, start with this post Setting up Rational Team Concert for API Development

Summary

A lot of effort went into making the Rational Team Concert Extension Workshop easier to consume and make it compatible to other RTC versions. I hope the result helps users out there to get started with RTC Extensibility and saves some of the precious time. If you have suggestions or run into problems, please provide feedback and questions on Jazz.net in the Forum.