It's all about the answers!

Ask a question

IBM Java 1.7 and RTC scm

Paul Newman (133) | asked Nov 28 '13, 8:59 p.m.
edited Dec 02 '13, 3:30 a.m. by Krzysztof Kaźmierczyk (7.4k372103)
I am trying to use the RTC scm command on a Redhat linux 6.3 system installed with IBM Java 1.7. When I run 'scm help' I get what looks like the normal help output  but an exception is thrown. here is the first few lines of output (the stack trace is rather long and perhaps not that useful).

$0-paulcnew@build3-rhel60:~> scm help
java.lang.IllegalStateException: Found two dtoEvolution elements with the same componentVersion value in bundle
    at java.util.TreeMap.put(
    at java.util.TreeSet.add(

<snip the rest of the stack trace and the normal output>

Is Java 1.7 supported by this version of RTC/scm or do I have to use some other version of Java or RTC?


2 answers

permanent link
Nick Edgar (6.5k711) | answered Nov 28 '13, 9:07 p.m.
Which version of RTC are you running?  This looks like a dup of Error in the log every time I start the client (Sun 1.7 VM) (213302), which was fixed in RTC 4.0.3.

Paul Newman commented Nov 29 '13, 12:29 p.m.

This is the name of the zip file I installed: so it looks like but scm -v outputs this:, version 3.1.100.v20120817_2130

Nick Edgar commented Nov 29 '13, 1:56 p.m.

It's 4.0 FP1 then.  The 3.1.100 version is for the plugin, which is more a reflection of API compatibility, not the product/release version.

There may also be a 'properties' folder as a sibling to scmtools and client, under which is a properties file giving more info about the product/release version.

Paul Newman commented Nov 29 '13, 3:14 p.m.

This machine is a build machine. As a result we installed build tools and scm tools but no graphical client. There is a properties directory in the install dir and it contains the following:
$0-paulcnew@build3-rhel60:/opt/ibm/jazz> find properties

Note there is no scm tools properties file so the version attributes in apply to the build tools. Is that correct?

And do you know why there is no properties file for the scm tools package?

thanks for your help.

Nick Edgar commented Nov 29 '13, 3:56 p.m.

I think it depends which download you installed.  If you're on one of the Enterprise platforms (AIX, Z/OS etc) they often include the SCM CLI as part of the build system toolkit.  If the SCM CLI really was installed separately, I'd expect it to have its own properties folder/file.

Paul Newman commented Nov 29 '13, 4:23 p.m.

Thanks again, Nick.
the SCM CLI came from a different zip file. here are the two zip files:

Paul Newman commented Nov 29 '13, 4:24 p.m. | edited Nov 29 '13, 5:20 p.m.

In order to confirm that the problem is indeed the IBM Java version, I removed the 1.7 RPM and installed a 1.6 RPM. The exception goes away. So, it appears it has something to do with 1.7. For now have modified the scm.ini file to point to the old java binary and that seems to work ok. (we can't remove IBM Java 1.7 as we need it for our product.) Meanwhile, I will investigate upgrading to a newer version of RTC. Can you recommend a version that will be best for Redhat 6.3 (on x86_64 architecture)? I imagine we can get any available version.

Nick Edgar commented Nov 29 '13, 5:22 p.m.
Hm, not sure why you didn't get a properties directory/file with the RTC-scmTools download. But in any case, it's pretty clear you're using

I'd suggest moving to the latest, 4.0.5, if possible.  Pretty sure the supported platforms didn't change much, but you should double check the system requirements page linked from the downloads page.

Piotr Aniola commented Dec 02 '13, 5:01 a.m.

Nick, is 4.0.5 available already? I believe that as of today, the last official version is 4.0.4.

Nick Edgar commented Dec 02 '13, 4:22 p.m.

Sorry, my mistake.  I thought it had already been posted, but there were some delays (in the other apps) that held this up.  I asked around, and the aim is to post it this Friday (Dec 6).

showing 5 of 9 show 4 more comments

permanent link
Steffen Weik (346) | answered Dec 16 '13, 5:37 a.m.
edited Dec 16 '13, 5:38 a.m.
I get this exception, too, even when using RTC 4.0.4 on Win 7.
It occurs as soon as I try to get the team repository from TeamPlatform:

    ITeamRepositoryService service = TeamPlatform.getTeamRepositoryService(); //<-- exception

Nick Edgar commented Dec 16 '13, 9:09 a.m.

Steffen, which version of the client libraries are you using? Which download did you get them from?

Nick Edgar commented Dec 16 '13, 9:10 a.m.

And which Java version?  The one included with RTC, or some other one, i.e. is it Java 7?

Steffen Weik commented Dec 17 '13, 6:09 a.m.

I get the exception with java 7 and both, the client libraries and the RTC server are 4.0.4

Steffen Weik commented Dec 17 '13, 6:10 a.m.

Also I use it on a 64bit architecture using 64bit libraries if available (I did not find one for the build toolkit)

Steffen Weik commented Dec 17 '13, 7:04 a.m.

Regarding your question about where I got the files from:
The libraries are those provided on the "all downloads" page on the jazz / RTC website. I took the files labelled as plain java zip files or something like that.

The jdk is not the one included with RTC but one distributed in our system (most probably these are the once provided by oracle). I tried both, a java 6, which worked fine for RTC and a java 7 which did not. Sadly I need to use java 7 because other parts of the environment rely on it.

Nick Edgar commented Dec 17 '13, 2:07 p.m.

Steffen, is the stack trace you're seeing exactly the same as the original here?  The problem was fixed in 4.0.3 and backported to 4.0.2.  I'm unable to reproduce it running the SCM CLI on my Mac using 4.0.3, against Oracle Java 7.

I see you're calling the Java client APIs yourself, presumably in a plain Java configuration (not running under OSGi). Is it possible you actually have multiple copies of the same plugin, for and in particular (you can ignore .nl[1|2] plugins, which just carry the string translations).

Steffen Weik commented Dec 18 '13, 12:44 p.m.

Ok, I am sorry. I reconfigured my complete environment and recognized that I got some confusion in RTC versions. I was partially using 4.0.4 and partially 4.0. Now I switched to 4.0.4 completely and everything is fine.
But I am still not sure, which libraries I should use. I have got the RTC-SDK-4.0.4 (which I am using currently) and the RTC-Client-plainJavaLib-4.0.4. Which one is preferable to use when creating custom ANT tasks? Which one when creating Extensions for RTC?

Nick Edgar commented Dec 18 '13, 1:13 p.m.

No problem, it can get confusing with the different versions for client side vs server side.

As for SDK vs plainJavaLib, the former has all the plugins to allow you to develop both client-side and server-side plugins.  The latter has just the client-side ones, and until recently did not include the plugin which you likely need for adding Ant tasks (assuming you want to take advantage of the class hierarchy used by our existing tasks).

Another way to think of it is that the SDK is for development time, and plainJavaLib is for runtime (client side only).

Nick Edgar commented Dec 18 '13, 1:23 p.m.

Actually, that's not quite right. We still don't include in the plainJavaLib, but it is included in the SDK.  The SDK has source, the plainJavaLib does not.  In your case, for developing Ant tasks, I would develop against the SDK, then either deploy the jar containing your classes into the buildtoolkit directory of the Build System Toolkit, or deploy it in a separate directory but that will require adding another -lib argument when invoking Ant.

Steffen Weik commented Jan 07 '14, 5:40 a.m.

You explained that the plainJavaLib is for runtime. Does it contain anything that a user would not have already installed using the p2 install repository?

Nick Edgar commented Jan 07 '14, 9:26 a.m. | edited Jan 07 '14, 9:27 a.m.

The p2 repo is for installing into an Eclipse IDE, so its plugins are intended to run in an OSGi/Equinox environment, not plain Java.  The plainJavaLib is intended for use outside an OSGi/Equinox environment.  As such it has a slightly different packaging for some of the jars, especially the ones from Apache.  Other than that, the main difference is that the p2 repo includes UI plugins whereas the plainJavaLib is lower level, containing just the (headless) client libraries.

showing 5 of 11 show 6 more comments

Your answer

Register or to post your answer.