It's all about the answers!

Ask a question

Post Build Participant - Build Engine Cannot find participant?

William Lacy (3136) | asked Aug 19 '14, 1:09 p.m.
edited Aug 19 '14, 4:23 p.m. by Stephanie Taylor (24115)
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!

sam detweiler commented Aug 19 '14, 3:34 p.m.

where did you put the build participant plugin?
if it provides UI, then it has to be in the Eclipse plugins folder to execute during the build definition editing,
and it also has to be in the build engines plugin folder to execute during the build

Accepted answer

permanent link
William Lacy (3136) | answered Sep 08 '14, 4:52 a.m.
edited Sep 08 '14, 4:55 a.m.
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: (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 :)
Ralph Schoon selected this answer as the correct answer

Ralph Schoon commented Sep 08 '14, 5:00 a.m.

Hi William,

this is complex stuff. And all you have is some examples.

If you happen to blog about this, please post a link to this question.


2 other answers

permanent link
Mike Brouwers (341318) | answered Sep 02 '14, 7:46 a.m.
I have the same issue. I exported the plugin (as a plugin jar) and copied it into the plugins folder of my jbe.
I keep getting the notification CRRTC3507W: Warning: An engine participant was not found for the post_build configuration element XXX

Are we forgetting a step?

permanent link
Mike Brouwers (341318) | answered Sep 02 '14, 9:18 a.m.
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.

Ralph Schoon commented Sep 02 '14, 9:36 a.m.

Yes, you have to be careful with the dependencies and version numbers if you develop with one version and run it on another. Best to use a minimum number. This might also be interesting:

sam detweiler commented Sep 02 '14, 10:03 a.m. | edited Sep 02 '14, 10:03 a.m.

sure would be nice if the default was NOT to set the versions.
this trips up too many folks

Ralph Schoon commented Sep 02 '14, 10:16 a.m.

This is a decision of the Eclipse PDE team. You can file a request or bug here. I found myself recently also going through the manifest, removing the versions for the same reasons.

Ralph Schoon commented Sep 02 '14, 10:18 a.m.

Should not have accepted the answer, that is something William should do. Please do so if this fixes your problem.

sam detweiler commented Sep 02 '14, 10:24 a.m.

removing the version dependent check is the first thing I do  before I test on my rtc servers.

another option would be to have the rtc server/process complain of some version mismatch.. instead of being quiet..  maybe that is something u could add to the workshop if its doable..

Ralph Schoon commented Sep 02 '14, 10:33 a.m. | edited Sep 02 '14, 10:34 a.m.

Sam, I will have a look. However, having the development server/jetty complain for the mismatch probably won't help a lot.In the workshop, the situation is, that you always will have a matching version. The problem appears if you deploy to a production environment with a different version, doesn't it?

sam detweiler commented Sep 02 '14, 11:49 a.m.

More training people to remove them except when needed for a particular reason. (I haven't seen one yet, all my stuff runs unchanged in 5.0).
but I would want some large warning trying to run a 5.0 toolkit plugin on a 4.0 system

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.