It's all about the answers!

Ask a question

unable to deploy RTC scm cli plugin


kanjbala jawahar (601815) | asked Oct 21 '13, 1:08 p.m.
retagged Dec 16 '13, 5:48 p.m. by David Lafreniere (4.8k7)
Hello,
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.


Comments
kanjbala jawahar commented Oct 24 '13, 11:40 a.m.

Hello, could you please give me an ETA for responding to this question.

Thanks much.

4 answers



permanent link
Nick Edgar (6.5k711) | answered Nov 04 '13, 4:51 p.m.
JAZZ DEVELOPER
Hi Kanjbala, sorry that this hasn't received any reply until now.

Can you clarify what you're trying to do, at a higher level?  Which part of the build system toolkit do you want to extend, the Ant tasks or JBE?  What are the extensions you're trying to make?

It's hard to tell just from the path what c:\rtc30 is referring to.  Is it a Build System Toolkit install, an RTC Eclipse client, or something else?

Comments
kanjbala jawahar commented Nov 06 '13, 10:41 a.m.

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.


Nick Edgar commented Nov 06 '13, 4:00 p.m.
JAZZ DEVELOPER

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.



kanjbala jawahar commented Nov 10 '13, 10:59 a.m.

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.


permanent link
sam detweiler (12.5k6195201) | answered Nov 10 '13, 11:43 a.m.
If you want to access jars from OUTSIDE the server runtime directory, you need to use the external keyword

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
kanjbala jawahar commented Nov 14 '13, 3:59 p.m.

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.


sam detweiler commented Nov 14 '13, 4:01 p.m.

you can send stuff to me.. sdetweil at gmail. not everything has to be external of course


kanjbala jawahar commented Nov 14 '13, 6:51 p.m.

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.


sam detweiler commented Nov 14 '13, 10:04 p.m.

show me the plugin.xml, and manifest.


kanjbala jawahar commented Nov 20 '13, 11:25 a.m.

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.


permanent link
kanjbala jawahar (601815) | answered Jan 06 '14, 12:54 p.m.
Hello Nick,
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.
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.

This is what I did, and was unsuccessful in getting the same results as you:
(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
Nick Edgar commented Jan 08 '14, 9:20 a.m.
JAZZ DEVELOPER

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.


With 3.x, you should be able to:
- copy the jars for com.ibm.team.build.common and com.ibm.team.build.client to scmtools/eclipse/plugins (you can get these from either the build system toolkit, or the RTC Eclipse client, e.g. under jazz/client/eclipse/plugins)
- copy your jars to scmtools/eclipse/plugins
- run scm with -clean the first time, to get it to re-scan the plugins directory

For debugging, also add: -debug -consoleLog
which will show any plugin resolution / dependency issues in the console output.


kanjbala jawahar commented Jan 08 '14, 11:14 a.m.

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:
C:\RTC-Client-Win-3.0.1.4\jazz\scmtools\eclipse\plugins
everything works great. But this is not acceptable.

But we want a better solution, that does not require moving jars around.

Are we saying that there is no other better solution for 3.x?


1
Nick Edgar commented Jan 08 '14, 3:21 p.m.
JAZZ DEVELOPER

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.



kanjbala jawahar commented Jan 08 '14, 4:22 p.m.

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.


permanent link
Nick Edgar (6.5k711) | answered Jan 08 '14, 12:39 p.m.
JAZZ DEVELOPER
At this point I don't see any better solution than copying the plugin jars.  

With the old update manager, you could point to different plugin 'sites', either by adding a site element to …eclipse/configuration/org.eclipse.update/platform.xml, or by adding an eclipse/links directory containing links files pointing to other sites.  So you could point to the RTC Eclipse client or JBE install directories to include their plugins, but this would bring in more than you want/need. e.g. the Eclipse client includes all the UI plugins, and JBE has extra plugins for the Ant tasks and build engine itself.

I tried the latter adding a file: /Users/nedgar/Downloads/Applications/SCM-CLI-3.0.1.4/eclipse/links/bst.link
containing:
path=../../BuildSystem-Toolkit-3.0.1.4/jazz/buildsystem/buildengine

It expects to find an eclipse directory under the referenced path, with a plugins directory under that.



Comments
Nick Edgar commented Jan 08 '14, 12:43 p.m. | edited Jan 30 '14, 12:23 p.m.
JAZZ DEVELOPER

This did bring in the build.common and build.client plugins, but also build.toolkit and build.engine. Running:

> ./scm.sh -debug -consoleLog -console -noexit help
and typing 'ss team.build' at the osgi> prompt produced:
389     <<LAZY>>    com.ibm.team.build.engine_3.0.2.v20110901_0306
392     RESOLVED    com.ibm.team.build.toolkit_3.0.2.v20110831_0247
                    Fragments=390, 391
595     RESOLVED    com.ibm.team.build.client_3.0.2.v20110831_0247
                    Fragments=381, 382
596     RESOLVED    com.ibm.team.build.common_3.0.3.v20120718_2351
                    Fragments=384, 385


Nick Edgar commented Jan 08 '14, 12:45 p.m. | edited Jan 30 '14, 12:24 p.m.
JAZZ DEVELOPER

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.


kanjbala jawahar commented Jan 08 '14, 1:37 p.m. | edited Jan 30 '14, 12:24 p.m.

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/


kanjbala jawahar commented Jan 08 '14, 1:38 p.m. | edited Jan 30 '14, 12:25 p.m.

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?


kanjbala jawahar commented Jan 08 '14, 1:39 p.m. | edited Jan 30 '14, 12:26 p.m.

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.



kanjbala jawahar commented Jan 30 '14, 11:22 a.m. | edited Jan 30 '14, 12:28 p.m.

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.


Nick Edgar commented Jan 30 '14, 12:29 p.m.
JAZZ DEVELOPER

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.

showing 5 of 7 show 2 more comments

Your answer


Register or to post 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.