It's all about the answers!

Ask a question

Is there an API alternative for RepoUtil.findNamedComponent?

kanjbala jawahar (601815) | asked Mar 17 '14, 3:36 p.m.
We have been extending RTC CLI piece for builds.
This plugin code is breaking on RTC client 4.x with this error:

Unexpected exception
java.lang.NoSuchMethodError: com/ibm/team/filesystem/cli/core/util/RepoUtil.findNamedComponent(Ljava/lang/String;Lcom/ib
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:

Thanks much in advance.

One answer

permanent link
Shashikant Padur (4.2k27) | answered Mar 18 '14, 4:55 a.m.
edited Mar 18 '14, 4:55 a.m.
From the following article:
The plain Java API zips are downloaded from 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.

If you have the IWorkspaceConnection, you can use the following:
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.

kanjbala jawahar commented Mar 19 '14, 1:37 p.m.

What I needed is the exact same functionality provided by findNamedComponent.
Taking a "uuid" selector and getting me a item handle for that, in this case the uuid selector is for a component.

I found another route to do that.
I replaced:

IComponent component = RepoUtil.findNamedComponent (componentName, wConnection, true, config);
final UUID id = RepoUtil.lookupUuid(componentName);
IComponentHandle componentHandle = (IComponentHandle) IComponent.ITEM_TYPE.createItemHandle(id, null);
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.

Tim Mok commented Mar 19 '14, 2:19 p.m.

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.

Note, RepoUtils is not API so any methods called from that is subject to change without notice.

kanjbala jawahar commented Mar 20 '14, 2:00 p.m.

Hello Tim,
I have the API docs that Shashikant mentions in his response. If I went by that, most of the code written by tWAS build team to extend SCM CLI would be unsupported.
That could not be the case!

I was under the impression that this documentation was work in progress. Not true?
I see no info. on packages such as* in these api docs.
We have to extend so much using that package and it's sub packages.

Please advise.

Tim Mok commented Mar 20 '14, 3:32 p.m.

It is the case as stated in the plain Java client API article:

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.

Here is a summarized version:
We have written a plugin (not plan Java clients) that extends SCM CLI.
We are extending the functionality of scm.exe.
To do the above, we need classes from package*, such as:


If I cannot use this package is there another package (supported) that helps me do this? I.e. add custom subcommands to scm.exe?

Shashikant Padur commented Mar 24 '14, 7:00 a.m.

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?

I have been advised that:

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

Shashikant Padur commented Mar 27 '14, 1:41 a.m.

 I have raised a workitem to address the documentation issue:

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

Thanks Shashikant.
I have added some comments to that work item.
My team will be following it closely.
Meanwhile we will use our best judgement to not use "internal" APIs.
When in doubt, I will continue using this post, at least until I get the updated API docs.

showing 5 of 9 show 4 more comments

Your answer

Register or to post 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.