RTC client 4.0.0.1 API not backward compatible with RTC client 3.0.1.1
This plugin has worked fine for past two years with RTC client 3.0.x.x.
Today we tried to upgrade to 4.0.x.x and our builds started failing with error:
Unexpected exceptionThe method findContentFor is not supported by RepoUtil.class in RTC cliient 4.0.0.1 API.
java.lang.NoSuchMethodError: com/ibm/team/filesystem/cli/core/util/RepoUtil.findContentFor(Lcom/ibm/team/repository/client/ITeamRepository;Ljava/lang/String;Lcom/ibm/team/file
system/common/IFileItemHandle;Lcom/ibm/team/filesystem/cli/core/subcommands/IClientConfiguration;)Ljava/io/InputStream;
at com.ibm.mrbuild.rtc.cli.internal.ExtractFilesCmd.run(ExtractFilesCmd.java:136)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(SubcommandLauncher.java:673)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.doStart(SubcommandLauncher.java:402)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(SubcommandLauncher.java:179)
at com.ibm.team.filesystem.cli.core.internal.Application.start(Application.java:50)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
Scm:
An error has occurred. See the log file
C:\Users\IBM_ADMIN\AppData\Local\jazz-scm\scratch\0\.metadata\.log.
4.0.x.x. jar containing RepoUtil.class is com.ibm.team.filesystem.cli.core_3.1.100.v20120822_0505.jar.
Please advise on how we should proceed with this.
Thanks in advance for your help.
2 answers
Comments
I understand.
My question still stands though.
WAS build needs this functionality. Even if API has changed, the functionality hopefully still remains.
So the WAS build team needs help in figuring out how we resolve this.
Thanks.
Can you call the scm command line? 'extract file <fileitemid> <filestateid> <destfilepath>'
Also note that if you keep your client side (SCM CLI + extensions) at 3.x level, it will still allow you to talk to a 4.x server.
Nick, the Rational team has asked that we all upgrade and not keep the compatibility between 3.0.1.1 and 4.0.0.1 because of severe performance impacts between the two, and performance improvement is the reason for updating to 4.0.0.5.
@Donald: Ok.
I see that the 'extract file' was added sometime after 3.0.1.1, but I cannot find any documentation for it anywhere other than the basic help on the command line. I do not see it in the latest info center for 4.0.5 either. http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m5/index.jsp?re=1&topic=/com.ibm.jazz.install.doc/topics/c_repotools_overview.html&scope=null
The extract seems to work. But, we now have an issue about finding the sateid of the file we want. We think that it has been dealt with in another area of the code but we are still looking.
If you have the versionable for the file (IFileItem extends IVersionable), then you can use IFileItem.getContent(), which returns an IFileContent (IFileContent extends IVersionedContent), then use IVersionedContent.getHash() to get the content hash, which only changes if the content is different. It's possible to have a different state of the file item without the actual content changing (e.g. due to a merge), so if you want to go by that you can use IVersionable.getStateId() (defined on super-interface IItemHandle).
We have gotten past the extract file problem that we last encountered.
Now, we have a new issue. 4001 is only allowing one credential at a time. We log in to 2 repositories and this works fine in 3011. But in 4001, if we log in to a repository all other credentials are removed. I need to research this more to find a workaround
Confirmed the problem of credentials, looking for a solution. Here is the scenario:
This looks interesting. Somewhat similar. https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=242038
@Donald Looking at the repositories.txt contents it seems like the repository id is the same for both the repositories. Earlier in 3.0.1, we used the repository uri as the key but in 4.0 we moved to using repository id as the key.
Shashikant Padur,
Yes the last parameter is a repository id. We do not recommend editing the repositories.txt file as we make calls to get the repository url from id. Since the both url's point to the same repository it may work but we cannot guarantee it.
Doesn't the SCM CLI allow you to point at different config dirs, via --config (can't remember the exact command line arg). Maybe that could be used as a workaround to support 2 different paths to the same repo.
We do need to find a good supported solution to this. We will be supporting multiple repositories at various levels and with proxies. I can re-code, which will take time, but I need to know a solution that works before I invest the effort.
We are now failing with the following error:
Has anybody seen the post above by Don Mason?
Should I submit another forum post for the above question(s):
--Unexpected exception java.lang.NoSuchMethodError: com/ibm/team/filesystem/cli/core/util/RepoUtil.findNamedComponent
--Is this another deprecated api? If so, what should we use?
--Also, how are we to know what apis we should be using?
We would like to see a response to the above; sooner the better.
Thanks.
Yes, I would suggest filing a separate question identifying the particular API call you are trying to make, e.g.:
Is there an API alternative for RepoUtil.findNamedComponent?
Thanks Geoffrey.
I have started a new post:
https://jazz.net/forum/questions/145694/is-there-an-api-alternative-for-repoutilfindnamedcomponent
for this question.
Comments
If you would like to use an internal rest api then you could try:
Thanks, but we would rather only use publicly documented methods. We are going to use the new 'extract file' command that was added. We are finishing up some code for finding a particular stateid of a file in a given snapshot. Once we have that working we should be ok with this problem. We will soon see.
You can use "scm -u y list remotefiles --snapshot <snapshot> <component> <remote-path>" to get to the itemid and stateid.
This looks promising, except that this looks like it requires the program to know the component. Can the component be left out. The snapshot should only have unique items so the command should be able to figure out the component if it needs it. Otherwise, I am left to now figure out the component of the file. If the component is optional, then this will be great.
The "remote-path" is relative to the component root, so you need to specify which component that remote-path should be interpreted against. If you were specifying the component name in the first segment of the remote-path, then you just need to parse out that first segment and use it as the component name.
Thanks. Hmm, we don't load with component names in the paths and we do not have the overlap. So, I guess this does not help us too much. We may want to use it, but we would now have to use a command to find the component name.