Is there an API alternative for RepoUtil.findNamedComponent?
This plugin code is breaking on RTC client 4.x with this error:
Here are additional questions:Unexpected exceptionjava.lang.NoSuchMethodError: com/ibm/team/filesystem/cli/core/util/RepoUtil.findNamedComponent(Ljava/lang/String;Lcom/ibm/team/scm/client/IWorkspaceConnection;ZLcom/ibm/team/filesystem/cli/core/subcommands/IClientConfiguration;)Lcom/ibm/team/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?
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
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);And I am getting the results I want.
IComponentHandle componentHandle = (IComponentHandle) IComponent.ITEM_TYPE.createItemHandle(id, null);
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.