SCM ignores our plugin after upgrade to 4.0.5 from 4.0.0.1
'scm -clean -v' with RTC v4.0.0.1 shows our plugin as loaded and the list of subcommands it adds.
The same command with v4.0.5 returns only the standard plugins that are loaded with the default deployment. Our plugin is ignored and is not listed in the output of loaded plugins.
Can anyone think of anything we are missing or might have misconfigured. In the past, we've occasionally encountered minor issues with changes to the JAVA API that necessitated changes to our plugin, but it has never failed to load before. I can't imagine that our plugin is now incompatible going from 4.0.0.1 to 4.0.5.
Even running with the -debug -consoleLog flags gives no useful clues. Our plugin does not show up at all in that output either; so, I am leaning toward some config problem. Is there some new config file or setting(s) that 4.0.5 needs for plugins that 4.0.0.1 does not?
Thanks.
5 answers
-
run
scm daemon startto start a long-lived subcommand. You should get output on the stdout of the CLI saying something likeListening on port 9999 ... - Telnet to port 9999.
- Run 'ss' to get a listing of bundles. Search for your bundle (using your terminal emulator's search command) and note the number in the left-most column.
- Now type 'diag your-bundle-number'. OSGi should tell you which bundles failed to resolve.
If so, this can cause your plugin to not load, silently.
Comments
Thanks for the suggestion.
Here are a few of the lines with versions from the META-INF/MANIFEST.MF file:
Bundle-Version: 2.0.0.qualifier
Require-Bundle: org.eclipse.core.runtime;bundle-version="3.5.0",
com.ibm.team.filesystem.cli.core;bundle-version="2.1.0",
com.ibm.team.filesystem.client;bundle-version="2.1.0",
com.ibm.team.repository.client;bundle-version="1.1.0",
com.ibm.team.repository.common;bundle-version="1.1.0",
...
<snip additional similar lines>
...
Can't list them all because of the character limit for comments, but you get the idea...
This plugin is a few years old. It has been modified over time to work with changes in the JAVA API, but has never failed to load before. To my knowledge, we have not modified these versions. I assumed they were just minimum thresholds, not exact version requirements. Am I wrong?
I'd suggest to check in the pulgin.xml and to make sure that this is the minimal version and not the specific version - or remove the versions altogether. This makes sure that the version numbers don't mismatch.
By default it is the minimal version, which should be fine. Check just in case.
Thanks. Just double checked the plugin.xml. I don't see anything that should override the default. This is the only line that I guess could affect it:
<?eclipse version="3.4"?>
But as this has been there and working across all the different versions until now, I didn't think it was a problem.
I think I'm just going to rebuild the plugin with a later version of the client and see where that gets me.
Is there a way to force scm to tell me why it is ignoring the plugin. (i.e. is there anything logged or some debug/tracing I can enable to see the logic it is using.) The -debug flag with the scm command didn't show anything, but maybe there's more info somewhere else?
As far as I am aware there have been no drastic changes to the API and if there were, you should see errors in the log files and not nothing.
(I work with Mike Phllpot and am working on this issue with him.)
1. This is an API issue, albeit internal API (more on this below).
2. We have extended SCM and a vast amount of interfaces have been changed between 4.0.0.1 to 4.0.5.
Our plugin extends the extension point com.ibm.team.filesystem.cli.core.subcommand and all of those packages/interfaces have been moved around (changed a lot) in 4.0.5.
We are extending, so we have no choice but to use internal APIs.
Having said that, can RTC folks/experts help us get out of this hole?
I went through the packages and decided that the extension point would now be:
com.ibm.team.rtc.cli.infrastructure.subcommand
I don't know if that is correct though, based on what I went over that seemed to be the right way to go.
After that I reduced the size of my code to bare minimum and fixed the compilation errors and exported the jar to the <RTC-Cliet-dir>/jazz/scmtools/eclipse location (eclipse automatically puts it under plugins).
Next I ran "scm -clean" followed by "scm -v" but I don't see my bundle.
What I should see is something like this: (showing what I see in 4.0.0.1)
C:\RTC-Client-Win-4.0.0.1\jazz\scmtools\eclipse>scm -v
Build Id: RTC-I20120911-1740
com.ibm.team.filesystem.cli.client, version 3.1.100.v20120817_2130
Subcommands: load login logout create create/workspace create/baseline create/changeset create/snapshot
<removed some stuff>
com.ibm.team.filesystem.cli.tools, version 3.1.100.v20120817_2130
Subcommands: tools.verify tools.validate tools.echo.stdin tools.metronome tools.pkgtest tools.configvalue tools.log
com.ibm.team.filesystem.cli.core, version 3.1.100.v20120822_0505
Subcommands: help version daemon daemon/start daemon/stop daemon/deregister daemon/register
com.ibm.mrbuild.rtc.cli, version 2.0.0.kishore_final3 <<===== My plugin extension.
Subcommands: mrbuild mrbuild/approveworkitem mrbuild/comparesnapshots mrbuild/createsnapshot mrbuild/extractsnapshots mrbuild/mapsnapshots <removed more stuff>
C:\RTC-Client-Win-4.0.0.1\jazz\scmtools\eclipse>
Thanks in advance for your help.
I will add more for others here later, but for now:
--the extension point that I replaced with is correct and is working now.
The underlying API was changed vastly and moved around into different packages/interfaces.
But since we are hooking into the subcommand interfaces we have to pay this price until we move on to a more reliable solution.