Extending the SCM command line
Is it possible to extend the SCM command line?
I poked around in the SDK and I think I figured out the proper extension point & Java interface (ISubcommand) but when I created a "Hello World" subcommand & dropped it into the plugins directory it wasn't recognized. Anything special I need to do here? |
Accepted answer
5 other answers
Note that the instance data location (aka Eclipse workspace) is different from the directory used to load your source (i.e. the sandbox). As far as the SCM CLI goes, it's mainly used just to store preferences.
I suggest looking at the extensions for the existing SCM CLI commands (in /com.ibm.team.filesystem.cli.client/plugin.xml) and use the same initpolicy as another command that's most similar to yours as far preference usage goes. For starters, maybe try initpolicy="scratch". |
Welcome to the wonderful world of OSGi. =)
The CLI isn't intended for customer extension, but it's possible. It sounds like OSGi doesn't know that the plugin is there. Try putting it into the dropins/ folder. Another alternative is to start the CLI with '-console' and '-consoleLog' in the commandline args. Stick a breakpoint on SubcommandLauncher#run() with Eclipse. When the breakpoint it hit, you should have access to an OSGi prompt, so you can query about your plugin to get the word directly from the horse's mouth. |
|
I got a little further using -clean to get my plugin recognized but now I've hit another problem (see full exception trace below).
I've tried everything I can think of: adding activators, adding org.eclipse.core.resources as a dependency, removing org.eclipse.core.resources as a dependency, minimizing dependencies, etc. How do the standard subcommands avoid this? Am I missing a dependency? !SESSION 2011-04-12 14:13:42.968 ----------------------------------------------- |
|
The failure:
java.lang.IllegalStateException: The instance data location has not been specified yet. occurs when Eclipse tries to access the instance data location, aka the Eclipse workspace location, when it has not been set. Normally this defaults to the 'workspace' directory under the current working directory, but the SCM CLI disables that with the "-data @noDefault" argument specified in the scm.sh script or the scm.ini file (used when running the scm executable). The SCM CLI sets the location by calling: com.ibm.team.filesystem.cli.core.util.SubcommandUtil.initializeEclipseWorkspaceRoot(File) Normally this is done in: com.ibm.team.filesystem.cli.core.internal.SubcommandDefinition.initialize(IExecutionContext, UserConfigDir, ICommandLine, ICommandLine) But whether it does so depends on the policy for the subcommand, as indicated by: com.ibm.team.filesystem.cli.core.internal.SubcommandDefinition.getInitPolicy() The policy is obtained from the extension for the subcommand. The code for gertInitPolicy() is:
Unfortunately, I'm not sure what those different policies actually mean. Evan or someone else from the CLI team would need to clarify. |
|
Great suggestion: list snapshots is close enough to what we're going (at least as far as logging in to the repo) & it uses "scratch".
I was using "none" initially (copied the plugin.xml stanza from version I think). I changed to scratch & it's all working now, thanks very much. Note that the instance data location (aka Eclipse workspace) is different from the directory used to load your source (i.e. the sandbox). As far as the SCM CLI goes, it's mainly used just to store preferences. |
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.