SCM ignores our plugin after upgrade to 4.0.5 from 4.0.0.1
We have a plugin under scmtools/eclipse/plugin that extends scm. It was working fine before we upgraded our RTC eclipse client to v4.0.5. Now scm does not "see" the plugin and does not load it.
'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.
'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
I've had success checking to see why a bundle didn't load using the OSGi console. The CLI makes that hard, since it eats the stdin, but you can tell OSGi to provide a console on a port by adding 'osgi.console=9999
' to configuration/config.ini
.
After doing that:
-
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 you look at your plugin build, META.INF, are the dependencies marked with specific versions?
If so, this can cause your plugin to not load, silently.
If so, this can cause your plugin to not load, silently.
Comments
Has the plugin been deployed to the new version of the SCM tools?
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.
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.
So, to Ralph, Sam and others:
(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 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.
So we finally figured it out.
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.
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.