Post Build Participant - Build Engine Cannot find participant?
Hi, I have small RTC extension project, which I have shared. This is to extend RTC to include a pre-build participant, within the ...engine plugin and the ui and config elements in the ...common plugin.
When right clicking and running as an eclipse application, I am able to create a new build with my new template, which is relying on the stuff contained within common. However, when running the build I get the following error:
2014-08-19 17:30:24 [Jazz build engine] CRRTC3507W: Warning: An engine participant was not found for the pre_build configuration element "Load Workspace from Build Tag". For more details, open the help system and search for CRRTC3507W.
I am presuming that I am missing an extra step, to make the build participant available to the build engines?
Please note, I am not actually that interested in my implementation in PreBuildParticipantLoadWorkspaceFromBuildTag class... I will be once I get the thing finding my build participant :)
Many Thanks!
Accepted answer
Hi Mike
Thanks for the response.
My final issue was also that the plugin was not resolving, but the underlying cause was different.
First for anyone else's benefit, I struggled to find the log that outputs errors on initialising the Jazz Build Engines. As this is an eclipse product, the log is in the workspace/.metadata/.log file. This is the log where you will see plugin initialisation failures. You can explicilty state the workspace that the JBEs use, by adding a -data <path_to_worskpace> to the jbe initialisation arguments.e
My final issue was that the classpath was not set correctly, and my plugin contained no compiled classes. I modified the Manifest's "Bundle-ClassPath" :
Bundle-ClassPath: .
Mike, I also experienced your issue before - To resolve your issue, and potentially further problems, I set my target environment in eclipse to be the JBE's plugin folder for both the engine and common parts of my plugin (as apposed to the RTC-SDK for example). I copied the JBE from the server here at work to ensure I had the same plugins as would be in my target runtime environment. Then for the ui part of the plugin, I used another workspace, where the target environment was the RTC-SDK with the same version as that of my target rtc version.
It probably is a good idea to subsequently remove versions in case you accept minor updates into the target environment, however, this reduced the risk of using incorrect methdos/classes due to different versions within the Javas Plain Apis and the RTC-SDK.
Another tip I have (I plan on writing a wiki somewhere) is to look at the existing build.common plugin written by the jazz team.
This sounds obvious, but finding all this stuff and how it pieces together was not for me. For example, the ant build participant has 3 plugins:
com.ibm.team.build.engine
com.ibm.team.build.common
com.ibm.team.build.client (or maybe .ui)
If you get the eclipse sdk, and add all those plugins in eclipse, you will be able to see all of the required classes that are described in the various tutorials. For example, a prebuild participant plugin:
PreBuildParticipant (Engine)
the Activator (UI)
ConfigurationElementEditor (UI)
ConfigurationElementEditorFactory (UI)
You can also see how this all hangs together in the plugin.xml and the manifest by unzipping these plugins and inspecting those files.
This got me past the final step of actually getting my plugin to work!
Hope this helps someone :)
Thanks for the response.
My final issue was also that the plugin was not resolving, but the underlying cause was different.
First for anyone else's benefit, I struggled to find the log that outputs errors on initialising the Jazz Build Engines. As this is an eclipse product, the log is in the workspace/.metadata/.log file. This is the log where you will see plugin initialisation failures. You can explicilty state the workspace that the JBEs use, by adding a -data <path_to_worskpace> to the jbe initialisation arguments.e
My final issue was that the classpath was not set correctly, and my plugin contained no compiled classes. I modified the Manifest's "Bundle-ClassPath" :
Bundle-ClassPath: .
Mike, I also experienced your issue before - To resolve your issue, and potentially further problems, I set my target environment in eclipse to be the JBE's plugin folder for both the engine and common parts of my plugin (as apposed to the RTC-SDK for example). I copied the JBE from the server here at work to ensure I had the same plugins as would be in my target runtime environment. Then for the ui part of the plugin, I used another workspace, where the target environment was the RTC-SDK with the same version as that of my target rtc version.
It probably is a good idea to subsequently remove versions in case you accept minor updates into the target environment, however, this reduced the risk of using incorrect methdos/classes due to different versions within the Javas Plain Apis and the RTC-SDK.
Another tip I have (I plan on writing a wiki somewhere) is to look at the existing build.common plugin written by the jazz team.
This sounds obvious, but finding all this stuff and how it pieces together was not for me. For example, the ant build participant has 3 plugins:
com.ibm.team.build.engine
com.ibm.team.build.common
com.ibm.team.build.client (or maybe .ui)
If you get the eclipse sdk, and add all those plugins in eclipse, you will be able to see all of the required classes that are described in the various tutorials. For example, a prebuild participant plugin:
PreBuildParticipant (Engine)
the Activator (UI)
ConfigurationElementEditor (UI)
ConfigurationElementEditorFactory (UI)
You can also see how this all hangs together in the plugin.xml and the manifest by unzipping these plugins and inspecting those files.
This got me past the final step of actually getting my plugin to work!
Hope this helps someone :)
2 other answers
I figured it out, in the MANIFEST.MF, the required bundles are depending on specific versions. Delete those versions (check the -consoleLog log to verify you don't have any more mismatches).
It should work now.
Comments
showing 5 of 7
show 2 more comments
Comments
sam detweiler
Aug 19 '14, 3:34 p.m.