Is there an API alternative for RepoUtil.findNamedComponent?
We have been extending RTC CLI piece for builds.
This plugin code is breaking on RTC client 4.x with this error: Here are additional questions: --Is this another deprecated api? If so, what should we use? --Also, how are we to know what apis we should be using? Nothing about the package, the class (RepoUtil) or the method gives me an indication that this is an internal call. What should I be looking for in future to avoid such issues? Just as fyi, this post came out of the back-and-forth one might see in post: https://jazz.net/forum/questions/143045/rtc-client-4001-api-not-backward-compatible-with-rtc-client-3011 Thanks much in advance. |
One answer
Shashikant Padur (4.3k●2●7)
| answered Mar 18 '14, 4:55 a.m.
JAZZ DEVELOPER edited Mar 18 '14, 4:55 a.m.
From the following article: https://jazz.net/library/article/1229
The plain Java API zips are downloaded from jazz.net. Go to the All Downloads section of the Rational Team Concert download page. Choose the version that matches the version of your RTC server to avoid any version mismatch problems. The Plain Java Client Libraries contains the JAR's and the Plain Java Client Libraries API documentation contains the javadoc HTML documentation for the available API's.
If you are looking to get the component id, then you could use the following command:
'scm -u y list components <workspace/stream name/uuid> --name <component name> --json'. You need to parse the uuid from the output.
IWorkspaceConnection wsConn;
// get the component handles for the workspace
List<IComponentHandle> compHandles = wsConn.getComponents();
// get the component names
List<IComponent> comps = wsConn.teamRepository().itemManager().fetchPartialItems(cHandles, IItemManager.DEFAULT, Collections.singletonList(IComponent.NAME_PROPERTY), null);
// or get the full component details
List<IComponent> comps = wsConn.teamRepository().itemManager().fetchCompleteItems(cHandles, IItemManager.DEFAULT, null);
and then compare the component name with each of the components in the component list.
Comments
kanjbala jawahar
commented Mar 19 '14, 1:37 p.m.
What I needed is the exact same functionality provided by findNamedComponent.
IComponent component = RepoUtil.findNamedComponent (componentName, wConnection, true, config);with: final UUID id = RepoUtil.lookupUuid(componentName);And I am getting the results I want. However I still have no idea about which calls would be internal and which not. I really need a answer to that question. So far in the process of RTC upgrade to 4.x client, we have encountered two "no such method found" exception. And both from RepoUtil class. I see no difference between the signatures of these methods vs. say method lookupUuid (which as of now is still supported). So how do I know which one is the next to go? Please advise. Anything listed in the documentation that Shashikant mentioned about the plain java client API is considered API. If you're using something not listed there, it's not API and is being used at your own risk.
kanjbala jawahar
commented Mar 20 '14, 2:00 p.m.
Hello Tim,
It is the case as stated in the plain Java client API article: https://jazz.net/library/article/1229.
Only the classes present in the HTML documentation are considered part of the public API. All other classes can change in ways that will break your code between releases. It is recommended that you use only the classes from the stable API.I would recommend using the method Shashikant suggests. That is a much stabler way going forward instead of relying on code that may change without warning.
kanjbala jawahar
commented Mar 20 '14, 11:12 p.m.
I don't think that works for what we are doing.
import com.ibm.team.filesystem.cli.core.cliparser.ICommandLine; If I cannot use this package is there another package (supported) that helps me do this? I.e. add custom subcommands to scm.exe? You can use the interfaces needed for the extension points to extend the cli but not the utility methods.
kanjbala jawahar
commented Mar 24 '14, 12:06 p.m.
I have no idea how I would go around figuring this out (i.e., which method I can and cannot use). If I can include a package and hence have access to the classes/interfaces in it and thus all its public methods, what criteria should I use for picking and choosing one over the other?
Only the classes present in the HTML documentation are considered part of the public API. All other classes ...Given the above I need to know exactly which interfaces/classes/packages I can and cannot use, since none of the packages under com.ibm.team.filesystem.* are in the api docs. Given a class that I can include, how would I pick and choose between its public methods? I need more specificity, please. Why is the process to know this kind of data w.r.t. to extending RTC API so cumbersome? When would I see these APIs in the supported API docs? I am losing valuable time while trying to figure this piece out. There is certain amount of urgency to this work, so please let me know what I can do to speed this process up. Thanks. I have raised a workitem to address the documentation issue: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=309572
kanjbala jawahar
commented Mar 27 '14, 12:47 p.m.
Thanks Shashikant.
showing 5 of 9
show 4 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.