unable to deploy RTC scm cli plugin
I am extending RTC SCM CLI for tWAS (Websphere) production build environment.
The entire coding/deploying process has been relatively smooth thus far.
So far we have been able to successfully extend the snapshot/baseline, work item, approval and other work flows.
This time I am extending parts of build system toolkit using the same plugin.
Until now, all the dependency jars for this plugin were right under:
C:\RTC-Client-Win-3.0.1.4\jazz\scmtools\eclipse\plugins
i.e. directly where the "scm -v" would look for them.
But for these new Jazz build engine classes (in the plugin) the dependency jars are located in another area of my file system:
c:\rtc30\plugins\com.ibm.team.build.client_3.0.2.v20110831_0247.jar
c:\rtc30\plugins\com.ibm.team.build.common_3.0.2.v20110831_0247.jar
not where "scm" looks for, I suppose.
So, I tried all of the variations shown below, with no success:
--adding Class-Path to manifest file:
Class-Path: \c:\rtc30\plugins\com.ibm.team.build.client_3.0.2.v20110831_0247.jar \c:\rtc30\plugins\com.ibm.team.build.common_3.0.2.v20110831_0247.jar
--set Windows 7 system classpath env. variable
.;C:\PROGRA~1\IBM\SQLLIB\java\db2java.zip;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc.jar;C:\PROGRA~1\IBM\SQLLIB\java\sqlj.zip;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cisuz.jar;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cu.jar;C:\PROGRA~1\IBM\SQLLIB\bin;C:\PROGRA~1\IBM\SQLLIB\java\common.jar;c:\rtc30\plugins\com.ibm.team.build.client_3.0.2.v20110831_0247.jar;c:\rtc30\plugins\com.ibm.team.build.common_3.0.2.v20110831_0247.jar
--I don't know how to pass classpath to scm.exe, so I tried to use lscm.bat:
SET PRGPATH=%~dp0
SET JAVA="C:\Program Files (x86)\IBM\Java60\jre\bin\java" <<< I changed it to my java.
SET SCM_DAEMON_PATH="%PRGPATH%scm.exe"
%JAVA% -Xquickstart -Xshareclasses -classpath "%PRGPATH%\plugins\com.ibm.team.filesystem.cli.minimal_3.0.2.v20110819_0209.jar;%PRGPATH%\plugins\com.ibm.team.filesystem.cli.core_3.0.3.v20120308_1209.jar;%PRGPATH%\plugins\com.ibm.team.filesystem.client.daemon_3.0.2.v20110819_0209.jar;%PRGPATH%\plugins\org.eclipse.equinox.common_3.5.1.R35x_v20090807-1100.jar;%PRGPATH%\plugins\com.ibm.team.filesystem.client_3.0.5.v20120531_0151.jar;%PRGPATH%\plugins\org.eclipse.osgi_3.5.2.R35x_v20100126.jar;%PRGPATH%\plugins\com.ibm.team.repository.common_1.3.100.v20120711_1525.jar;c:\rtc30\plugins\com.ibm.team.build.client_3.0.2.v20110831_0247.jar;c:\rtc30\plugins\com.ibm.team.build.common_3.0.2.v20110831_0247.jar;." com.ibm.team.filesystem.cli.minimal.client.FrontEndClient "lscm" %*
None of the above worked.
However, as soon as I copy and place those jars under:
C:\RTC-Client-Win-3.0.1.4\jazz\scmtools\eclipse\plugins
everything works great. But this is not acceptable.
I need to be able point to these jar dependencies, not bundle them with my plugin jar.
I need to do this for both windows and unix environments.
Please advise.
Thanks in advance.
4 answers
Comments
Hi Nick,
I am trying to set a build engine active/inactive as needed, for now (later we might do more).
Our plugin until now has been only dealing with SCM related tasks and artifacts such as:
--snapshots
--workspace /streams
--changesets, workitems, approvals etc.
But we now need to extend it to work with build engine(s)/definitions etc.. So yes, the two jars that I am referring to are part of the build system tool kit.
If one installed the build system toolkit, these two jars would be found under:
<install dir>/jazz/buildsystem/buildengine/eclipse/plugins
However, in my eclipse plugin development environment, the c:\rtc30 points to the RTC SDK for 3.0.1.X.
I mainly use c:\rtc30 as my "target platform" in eclipse to have access to the javadocs for the RTC API.
How do I get these two jars in the plugin's class path, or is there some other way?
Copying them to where I need them is not acceptable.
I don't have the build system toolkit installed in my windows environment.
Let me know if you need more info.
Thanks.
If you have the SDK as your target platform, then com.ibm.team.build.common and com.ibm.team.build.client should already be in there. You should be able to add them to your plugin's classpath in the same way you did for any of the other plugins you're compiling against. I recommend using a plugin project and using PDE's support for compiling against different plugins, even if the code will eventually run as a plain Java client (not under Eclipse/Equinox, i.e. OSGi). That way managing dedendencies is much easier -- you can just add prereq plugins using the plugin manifest editor.
Nick, I did try it. As you will see from my original question, I added these two jars to my manifest and it did not help.
Only adding those two jars physically to the location I mention works.
Let me know if you would like to see how the manifest looks.
Or any other files.
Since SDK is in my target platform the plugin project builds cleanly.
But when I export the jar, it fails to recognize my plugin unless I move those two jars to the location I mentioned above.
Thanks.
Bundle-ClassPath: .,
external:C:/Users/Delljoaobosco/Desktop/lib.jar,
external:C:/Users/Delljoaobosco/Desktop/usdclient.jar,
note that this will only work where the paths are correct (and the server has access to those folders/files) of course
Comments
Ok, this fixes one aspect but breaks another piece. I would like to show what I am talking about. Is it possible to do this in a non-forum format, until we figure out the fix?
Thanks.
you can send stuff to me.. sdetweil at gmail. not everything has to be external of course
I will not be able to send company confidential source to external email.
So I need to think little bit about how to proceed with this.
show me the plugin.xml, and manifest.
Sam, I will get back to you regarding the plugin.xml and manifest after I have tried a couple of things.
Thanks for all the help.
I tried your instructions, at least as best as I could, not knowing your complete environment.
These were your instructions:
I did some explorations on Friday, but this was hampered by the fact that the SCM CLI in RTC 4.x is missing the P2 bundles for supporting dropins, which would explain why putting the bundles in dropins wasn't having any effect.This is what I did, and was unsuccessful in getting the same results as you:
I was able to get a simple case working, where an added command depends on the Build client APIs, but I had to directly modify the simple configurator's list of bundles:
I put the jar for my test bundle (com.ibm.team.build.test.scm-cli-ext) in a new sibling to the plugins folder, called build, then changed .../jazz/scmtools/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info to have:
com.ibm.team.build.client,3.0.500.v20130315_0142,../../client/eclipse/plugins/com.ibm.team.build.client_3.0.500.v20130315_0142.jar,4,false
com.ibm.team.build.common,3.1.400.v20130415_0257,../../client/eclipse/plugins/com.ibm.team.build.common_3.1.400.v20130415_0257.jar,4,false
com.ibm.team.build.test.scm-cli-ext,1.0.0.201311211716,build/com.ibm.team.build.test.scm-cli-ext_1.0.0.201311211716.jar,4,false
Note that it's getting my new test bundle from under 'build', and the build.common and build.client from the RTC Eclipse client under .../jazz/client.
(I was not sure about some of the instructions, so I made my own assumptions at some places, as you will see below.)
Here is why I made some assumptions:
1. I do not have a .../jazz/scmtools/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
but I do have a ...\jazz\client\eclipse\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info (see the difference).
2. You said:
"I put the jar for my test bundle (com.ibm.team.build.test.scm-cli-ext) in a new sibling to the plugins folder, called build, then changed ..."
Sibling to which plugins folder?
jazz\client\eclipse\plugins or jazz\scmtools\eclipse\plugins
I chose jazz\client\eclipse\plugins due to the location of file bundles.info in my environment.
Next, I did this:
--Created a sibling dir called "build" to jazz\client\eclipse\plugins
--Placed my bundle jar in there, namely, com.ibm.mrbuild.rtc.cli_2.0.0.testengine.jar
--Modified jazz\client\eclipse\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info to have the following line:
com.ibm.mrbuild.rtc.cli,2.0.0.testengine,build/com.ibm.mrbuild.rtc.cli_2.0.0.testengine.jar
this bundles.info already had the following two lines:
com.ibm.team.build.client,3.0.2.v20110831_0247,plugins/com.ibm.team.build.client_3.0.2.v20110831_0247.jar,4,false
com.ibm.team.build.common,3.0.2.v20110831_0247,../../../../rtc30/plugins/com.ibm.team.build.common_3.0.2.v20110831_0247.jar,4,false
Then I ran "scm -v" from under the ...\jazz\scmtools\eclipse directory and got no info. on my bundle.
I need to be able to see the following info for my bundle:
com.ibm.mrbuild.rtc.cli, version 2.0.0.testengine
Please let me know what I am missing or where I am going wrong.
Also as you can see it is difficult to do this via forum. I would like to continue this offline until we fig. out the solution and once we arrive at the answer I can post it here.
I am assuming you wanted me to post this data here and not in the work item that you opened, i.e., work item 292967.
Comments
Hi Kanj, I was using RTC 4.x, which I assumed worked the same as RTC 3.x for how plugins got deployed by the SCM CLI, but it turns out 3.x does not use the P2 simple configurator, but rather the older Eclipse update manager. This explains why you don't have scmtools/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info. My apologies for the resulting confusion.
Nick, I have already done what you have described and that works.
But that is what we want to avoid doing.
If you read my first post, you will see that I got it to work the way you described above.
Here is the excerpt from the first post:
However, as soon as I copy and place those jars under:But we want a better solution, that does not require moving jars around.
C:\RTC-Client-Win-3.0.1.4\jazz\scmtools\eclipse\plugins
everything works great. But this is not acceptable.
Are we saying that there is no other better solution for 3.x?
I guess it depends on the existing install that you expect your users to have, that your stuff will install into. If it has the layout above, and you can rely on buildsystem being there as a sibling to scmtools, then you could use my approach above of including the buildsystem/buildengine directory as a link from scmtools/eclipse/links. If not, you'll either have to get them to install in this way manually first, or bring along your own copies of the relevant Build plugin jars.
1 vote
Thanks Nick. Yes, we (tWAS build team) will own the installations, so we can configure the setups as needed.
I will try your approach and get back to you with the results in a day or two.
Comments
This did bring in the build.common and build.client plugins, but also build.toolkit and build.engine. Running:
Maybe having these extra plugins around is OK for you. But then this requires laying down a Build System Toolkit install in addition to the SCM CLI. If you can assume your SCM CLI install is from the one for the RTC Eclipse client, then it's probably easier to just copy the build.common and build.client plugins from there into the SCM CLI's plugins directory.
Nick I am trying to understand what you have described above but am struggling a bit.
So my apologies if I am repeating myself or you.
Having said that, I am fine with bringing in all those bundles. No problem there.
Especially since, In our production environment (Unix), we have:
wsbld174 -> pwd
/buildserver/tools/rtc/Linux-3.0.1.1/jazz
wsbld174 -> ls -l
total 8
drwxr-xr-x 7 bbuild build 4096 Oct 06 2011 buildsystem/
drwxr-xr-x 5 bbuild build 256 Oct 06 2011 client/
drwxr-xr-x 3 bbuild build 256 Oct 06 2011 properties/
drwxr-xr-x 3 bbuild build 256 Oct 06 2011 scmtools/
Continued:
wsbld174 -> cd buildsystem/
/buildserver/tools/rtc/Linux-3.0.1.1/jazz/buildsystem (botp:mrbuild2)wsbld174 -> ls -l | egrep '^d'
drwxr-xr-x 2 bbuild build 256 Oct 06 2011 buildagent/
drwxr-xr-x 3 bbuild build 256 Oct 06 2011 buildengine/
drwxr-xr-x 4 bbuild build 16384 Oct 06 2011 buildtoolkit/
drwxr-xr-x 2 bbuild build 4096 Oct 06 2011 license/
drwxr-xr-x 2 bbuild build 256 Oct 06 2011 maven/
wsbld174 ->
So given the above, do you think there is a way to point to the dependency jars (build.common and build.client) without actually moving them to scmtools/eclipse/plugins and have things work?
Continued: (Why this limit on commenting?)
And if there is a way pls. give me as detailed info. as possible.
For example, there are multiple plugins dirs. etc. and I will need to know which one you actually mean etc. All this assuming that there is a way to get things to work. I will replicate my production environment in my sandbox environment, if you tell me that there is a way to get things to work without moving the dependency jars around.
Hope I have not confused the matter :).
Thanks much.
Hello Nick,
The link approach works wonderfully for the tWAS build team.
Now we are able to use the same plugin (build team's custom plugin) for both SCM related work as well as the build system toolkit related work.
Thanks much for all your help.
P.S. I want to accept your answer but not sure where to mark that. I don't want to mark the top one (the one on Nov. 4, 2013), because that one is not really the solution that worked for us. Anyway wanted to let you know.
Hi Kanj, good to hear. I've refactored the thread a bit so you can mark the last answer as accepted. It would be good if you could post a brief summary of how you used the links folder approach in the end.
Comments
kanjbala jawahar
Oct 24 '13, 11:40 a.m.Hello, could you please give me an ETA for responding to this question.
Thanks much.