IBM Java 1.7 and RTC scm
Paul Newman (1●3●3)
| asked Nov 28 '13, 8:59 p.m.
edited Dec 02 '13, 3:30 a.m. by Krzysztof Kaźmierczyk (7.5k●4●80●103)
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 com.ibm.team.scm.common. at com.ibm.team.repository.common.internal.util.ModelElementDescriptor$EvolutionDescriptorComponentVersionComparator.compare(ModelElementDescriptor.java:223) at com.ibm.team.repository.common.internal.util.ModelElementDescriptor$EvolutionDescriptorComponentVersionComparator.compare(ModelElementDescriptor.java:1) at java.util.TreeMap.compare(TreeMap.java:1188) at java.util.TreeMap.put(TreeMap.java:531) at java.util.TreeSet.add(TreeSet.java:255) at com.ibm.team.repository.common.internal.util.ModelElementDescriptor.processEvolutionElement(ModelElementDescriptor.java:70) at com.ibm.team.repository.common.internal.util.ModelElementDescriptor.processChild(ModelElementDescriptor.java:63) at com.ibm.team.repository.common.transport.AbstractElementDescriptor.processChildren(AbstractElementDescriptor.java:725) <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? thanks. |
2 answers
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.
Comments
Paul Newman
commented Nov 29 '13, 12:29 p.m.
This is the name of the zip file I installed: RTC-scmTools-Linux64-4.0.0.1.zip so it looks like 4.0.0.1 but scm -v outputs this:
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:
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.
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.
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 4.0.0.1.
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.
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
|
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: TeamPlatform.startup(); ITeamRepositoryService service = TeamPlatform.getTeamRepositoryService(); //<-- exception Comments Steffen, which version of the client libraries are you using? Which download did you get them from? 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:
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 com.ibm.team.repository.common and com.ibm.team.rtc.common 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.
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 com.ibm.team.build.toolkit plugin which you likely need for adding Ant tasks (assuming you want to take advantage of the com.ibm.team.build.ant.task.AbstractTeamBuildTask 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).
Actually, that's not quite right. We still don't include com.ibm.team.build.toolkit 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?
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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.