It's all about the answers!

Ask a question

RTC client API not backward compatible with RTC client

kanjbala jawahar (601815) | asked Feb 20 '14, 11:52 p.m.
WAS build team uses a custom plugin (written by us) to extend scm command line.
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 exception
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
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
        at org.eclipse.equinox.launcher.Main.invokeFramework(
        at org.eclipse.equinox.launcher.Main.basicRun(
An error has occurred. See the log file
The method findContentFor is not supported by RepoUtil.class in RTC cliient API.
4.0.x.x. jar containing RepoUtil.class is

Please advise on how we should proceed with this.

Thanks in advance for your help.

2 answers

permanent link
Shashikant Padur (4.2k27) | answered Feb 21 '14, 12:06 a.m.
edited Feb 21 '14, 12:08 a.m.
The RepoUtil is not a public API and is used internally. It is subject to change and will not adhere to the API guidelines. With respect to the command line, the commands and its arguments/options is considered as API.

kanjbala jawahar commented Feb 21 '14, 12:28 a.m.

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.


Shashikant Padur commented Feb 21 '14, 12:50 a.m.

Can you call the scm command line? 'extract file <fileitemid> <filestateid> <destfilepath>'

Nick Edgar commented Feb 21 '14, 8:30 a.m.

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.

Donald Mason commented Feb 21 '14, 9:00 a.m.

Nick, the Rational team has asked that we all upgrade and not keep the compatibility between and because of severe performance impacts between the two, and performance improvement is the reason for updating to 

Nick Edgar commented Feb 21 '14, 9:17 a.m.

@Donald: Ok. 

Can you call the scm command line? 'extract file <fileitemid> <filestateid> <destfilepath>'
@Shashi: they are extending the SCM CLI with their own commands. Can you recommend an API (or even non-API, that you would use as a command implementor)  they can use that would be equivalent to RepoUtil.findContentFor?

Donald Mason commented Feb 21 '14, 12:36 p.m.

I see that the 'extract file' was added sometime after, 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.

Where can I find the documentation for this new command?  We are trying out with options that seem to make sense, but we want to know for sure.  Especially the <filestateid>  

Donald Mason commented Feb 21 '14, 4:01 p.m.

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.

We need to be able to find the stateid of the file that would come with any given snapshot we provide.  Then we extract that file.  Then we compare against modern data to determine a future action.  

Still looking, but if anyone has a faster, well documented way of doing it, I would appreciate it.

Nick Edgar commented Feb 24 '14, 8:25 a.m.

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).

Donald Mason commented Feb 25 '14, 10:07 a.m.

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 

Donald Mason commented Feb 25 '14, 10:24 a.m.

 Confirmed the problem of credentials, looking for a solution.   Here is the scenario:

home ->  /server/tools/rtc/Linux- login  -r REPOSITORY1 -u ID -P PASS
Logged in to REPOSITORY1
wsbld174 -> cat /home/dons/.jazz-scm/repositories.txt
### reporeg 0
home ->  /server/tools/rtc/Linux- login  -r REPOSITORY2 -u ID -P PASS
Logged in to REPOSITORY2
home -> cat /home/dons/.jazz-scm/repositories.txt
### reporeg 0

Donald Mason commented Feb 25 '14, 10:51 a.m.

This looks interesting.  Somewhat similar. 

Shashikant Padur commented Feb 25 '14, 10:55 p.m.

@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. 

Was repository2 DB cloned from repository1? I don't think that is a supported configuration where you have two repositories with the same repository ID.

The workitem item you pointed out fixes one of the issues that was related to the change where the scm metadata now stores repository id.

Donald Mason commented Feb 26 '14, 12:17 p.m.

 Shashikant Padur,

We have a proxy.  For some actions we go the real server and for some (like load) we go through a proxy for performance.  
So is the new last parameter on the line a repository uuid?  

Is there some reason that we should not update the repositories.txt file to put in the entries we want and then never do logins until the password changes?

Shashikant Padur commented Feb 26 '14, 11:06 p.m.

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.

Nick Edgar commented Feb 27 '14, 8:33 a.m.

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.

Donald Mason commented Feb 27 '14, 10:42 a.m.

 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.

For now, the only solution that we have found, is to hardcode the repositories.txt file.  It is working so far.

Donald Mason commented Feb 27 '14, 2:39 p.m.
We run the following command that needs to find the pretty name of the component: mrbuild commentbaseline  -r REPOSITORY -w _WdtoMAiqEeKxuYvdzgP5Bg -c _-I2IYAikEeKxuYvdzgP5Bg --baseline _WNXZ8pXr
EeOAt7jdSvRXig "Committed - x1408.01 - 2014/02/27 11:19:34 CST - Production Build"

We are now failing with the following error:

Unexpected exception
java.lang.NoSuchMethodError: com/ibm/team/filesystem/cli/core/util/RepoUtil.findNamedComponent(Ljava/lang/String;Lcom/ib

Is this another deprecated api?  If so, what should we use?   Also, how are we to know what apis we should be using? 

kanjbala jawahar commented Mar 14 '14, 12:21 p.m.

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.

Geoffrey Clemm commented Mar 14 '14, 1:30 p.m.

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?

kanjbala jawahar commented Mar 17 '14, 3:53 p.m.
showing 5 of 20 show 15 more comments

permanent link
Donald Mason (5144) | answered Feb 21 '14, 10:08 a.m.
 I just looked and that extract file is new in  It was not in the 
We will see if that will work.

Shashikant Padur commented Feb 23 '14, 10:24 p.m. | edited Feb 23 '14, 10:35 p.m.

If you would like to use an internal rest api then you could try:

workspaceitemid & componentitemid could be "-" if you have provided the itemid and stateid or path.
or RepoUtil.httpDownloadFile(...) but that takes in a stateid.
Disclaimer: Please note that this is an internal api and is subject to change. Use at your own risk.

Donald Mason commented Feb 24 '14, 9:27 a.m.

 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.

Shashikant Padur commented Feb 24 '14, 11:21 p.m.

You can use "scm -u y list remotefiles --snapshot <snapshot> <component> <remote-path>" to get to the itemid and stateid.

Donald Mason commented Feb 26 '14, 12:23 p.m.

 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.

Geoffrey Clemm commented Feb 26 '14, 3:48 p.m.

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.

Donald Mason commented Feb 26 '14, 4:14 p.m.

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. 

showing 5 of 6 show 1 more comments

Your answer

Register or to post your answer.