RTC 6.0 – Does the API Change and Break my Code?


I was curious if there will be a lot of rework needed to bring extensions and automation over to RTC 6.0. Here is what I have seen so far.

I found the time to setup my RTC 6.0 environment for Extensions development. This went very smoothly and did not differ to what I describe in Running the RTC Extensions Workshop With RTC 6.0. I then brought all the extensions, API and automation examples from my RTC API Development environment over into the new workspace in the RTC 6.0 environment.

I did not see any errors except in the code related to Contributing Attribute Presentations and the error can likely be fixed by using a different method. So although my API code touches a broad range of the API in RTC, there are only minor changes. The majority of the API seems to be very stable, since this was also the case when I brought over my code into RTC 4.0 some years ago.

There are likely additions to the API, but the API that is there seems to be very stable otherwise. This includes even internal API that I have used on some occasions. Of course, you still want to test that everything work after you brought it over.

I have to confess that I am so far doing the majority of the work in an environment based on RTC 4.0.1. The reasons are basically that RTC 5.x had an annoying issue as explained in Running The RTC 4.x Extensions Workshop With RTC 5.0.x. Since I did not want to put up with it all the time I kept working with 4.0.1 and only tested the result in different versions.

Summary

The RTC client and server API used in extensions and for automation seems to be very stable and there should be not a lot of effort required to bring over your own automation and extensions over to RTC 6.0

As always I hope this saves users out there some time and worries.

Advertisements

About rsjazz

Hi, my name is Ralph. I work for IBM and help colleagues and customers with adopting the Jazz technologies.
This entry was posted in Jazz, RTC Automation, RTC Extensibility and tagged , , , , , , . Bookmark the permalink.

14 Responses to RTC 6.0 – Does the API Change and Break my Code?

  1. Tuan says:

    Hello Ralph,
    In RTC Eclipse client, I’m looking for possibilities to display dynamic, context-sensitive help when user navigates from Work Item to Work Item. Until now I am able to contribute to Eclipse dynamic help and populate contents when the user opens the Work Item editor, but I am not able to get Work Item object being viewed, therefore I can’t display help contents based on current Work Item’s information. I didn’t find any information from IBM & jazz.net about this topic, could you please give me some inside hints about this topic? Is it supported from IBM to extend the Eclipse client in this way?
    Thank you.

    • rsjazz says:

      I don’t understand what “not able to get Work Item object being viewed” means. I haven’t looked into this topic at all. If there is Eclipse capability to extend editors, it is basically an Eclipse capability and not something that is specific for RTC. I would look there. You could try to use Plugin Spy (Shift-Alt-F1) or Yari to find the ID’s and objects.

      • Tuan says:

        Hi, thanks for your reply. About my question, what I would mean is: I want to display different help contents based on the type of displayed/viewed/opened Work Item in the editor. I could populate help content when the Work Item editor is opened, but I couldn’t get the information of the Work Item is being viewed in the editor, such as ID, Type… I want to use this information to form my help contents.

      • rsjazz says:

        Start here to understand the RTC API: https://rsjazz.wordpress.com/2013/03/20/understanding-and-using-the-rtc-java-client-api/

        Use Yari or Plugin Spy to find out what objects the view has and then use the API to access the work item from them. The view might have a proxy class.

        This is pretty much all I can say.

    • rsjazz says:

      You can create extensions to Eclipse if you want, but IBM does not support your extensions. If you run into trouble with your own extensions, IBM support will not b able to help.
      I can’t speak for IBM here, but my understanding is IBM supports the Plain Java Client Libraries as it is available and works, but usage of APIs is use on your own risk.

  2. Vlad says:

    Hello Ralph,

    We are using curently using RTC 4.0.7 and plan to upgrade to 5.x or 6.x . I’m using the REST api for linking SVN commits to RTC workitems . Is RTC 6.x keeping this REST API ?

    Thank you !

    • rsjazz says:

      As far as I can tell, the API’s are kept. But there might be changes to the API’s e.g. a new new version with differences. You should definitely test your integrations on a test system.

      I have seen almost no changes in the Java API’s but also for these I would always suggest to check for broken API, deprecation, recompile them with the development environment for the new version and make sure extensions still work.

  3. Philipp says:

    Hello Ralph,

    Do I have to update the PlainJavaAPI Library as well?

    My application works fine for CLM 4 & 5, but it response an error “Your client is version 4.0, and the server is version 6.0.1. These versions are not compatible.” for CLM 6.
    The error occurs during the log in.

    Thank you for your help!

  4. Lucas Pascoal says:

    Hi Ralph,
    We are upgrading from version 5.0.2 to 6.0.2 of CLM, and we are coming across problems related to custom advisors.
    Some of these were using the method “serializeVariableValues” class “WorkItemTemplateSerializable” and this method was removed with updating plugins in this version, specifically the file “com.ibm.team.workitem.common_3.2.500.v20151021_2014.jar”.
    Have any suggestions to solve this problem? Rewrite the code using a compatible method?
    Thanks!

    • rsjazz says:

      There is currently a problem with the 6.0.2. SDK, that prevents you from developing with it. See my blog (search for 6.0.1).

      com.ibm.team.workitem.common.internal.template.WorkItemTemplateSerializable is an internal class that you should not use. If you use those and the API breaks, check where they have used in the previous product code/sdk and check the new usage.

      Alternatively open the class and check for what methods are available now. In this case check if com.ibm.team.workitem.common.internal.template.WorkItemTemplateSerializable.serializeVariableAndParameterValues(Map, Map) does what you want.

      For external API they usually deprecate the class/method and add a description how to convert into the JavaDoc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s