RTC client 4.0.0.1 API not backward compatible with RTC client 3.0.1.1
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 exceptionThe method findContentFor is not supported by RepoUtil.class in RTC cliient 4.0.0.1 API. 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
Shashikant Padur (4.3k●2●7)
| answered Feb 21 '14, 12:06 a.m.
JAZZ DEVELOPER 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.
Comments I understand.
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.
> 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?
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
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>
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.
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.
Confirmed the problem of credentials, looking for a solution. Here is the scenario:
home -> /server/tools/rtc/Linux-4.0.0.1/jazz/scmtools/eclipse/scm.sh login -r REPOSITORY1 -u ID -P PASS
Logged in to REPOSITORY1
wsbld174 -> cat /home/dons/.jazz-scm/repositories.txt
### reporeg 0
REPOSITORY1,,ID,,false,PASS,_MuBtAK_1Ed24Wf1YXJySrQ
home -> /server/tools/rtc/Linux-4.0.0.1/jazz/scmtools/eclipse/scm.sh login -r REPOSITORY2 -u ID -P PASS
Logged in to REPOSITORY2
home -> cat /home/dons/.jazz-scm/repositories.txt
### reporeg 0
REPOSITORY2,,ID,,false,PASS,_MuBtAK_1Ed24Wf1YXJySrQ
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.
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.
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?
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.
For now, the only solution that we have found, is to hardcode the repositories.txt file. It is working so far.
We run the following command that needs to find the pretty name of the component:
scm.sh 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
m/team/scm/client/IWorkspaceConnection;ZLcom/ibm/team/filesystem/cli/core/subcommands/IClientConfiguration;)Lcom/ibm/tea
m/scm/common/IComponent;
Is this another deprecated api? If so, what should we use? Also, how are we to know what apis we should be using?
Has anybody seen the post above by Don Mason?
Geoffrey Clemm
commented Mar 14 '14, 1:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, I would suggest filing a separate question identifying the particular API call you are trying to make, e.g.:
Thanks Geoffrey.
showing 5 of 20
show 15 more comments
|
I just looked and that extract file is new in 4.0.0.1 It was not in the 3.0.1.1
We will see if that will work.
Comments 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.
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.
Geoffrey Clemm
commented Feb 26 '14, 3:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
showing 5 of 6
show 1 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.