Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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:

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

1 vote



One answer

Permanent link
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.

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.

1 vote

Comments

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);
with:
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.

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.

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 com.ibm.team.filesystem.* in these api docs.
We have to extend so much using that package and it's sub packages.

Please advise.


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.

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 com.ibm.team.filesystem*, such as:

import com.ibm.team.filesystem.cli.core.cliparser.ICommandLine;
import com.ibm.team.filesystem.cli.core.cliparser.IOptionKey;
import com.ibm.team.filesystem.cli.core.cliparser.NamedOptionDefinition;
import com.ibm.team.filesystem.cli.core.cliparser.Options;
import com.ibm.team.filesystem.cli.core.cliparser.PositionalOptionDefinition;
import com.ibm.team.filesystem.cli.core.subcommands.IClientConfiguration;
import com.ibm.team.filesystem.cli.core.subcommands.IOptionSource;
import com.ibm.team.filesystem.cli.core.subcommands.ISubcommand;
import com.ibm.team.filesystem.cli.core.util.SubcommandUtil;
etc.

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.

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

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 log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,944

Question asked: Mar 17 '14, 3:36 p.m.

Question was seen: 4,362 times

Last updated: Mar 27 '14, 12:47 p.m.

Confirmation Cancel Confirm