Creating custom Pre-Build and Post-Build options
I would like to create custom Pre-Build and Post-Build options that would be available to all build definitions in my repository. Currently there is only a 'Jazz Source Control' option for Pre-Build tasks, and 'ECJ Publishing' and 'Junit Publishing' for Post-Build tasks. The dialog layout leads me to believe that this functionality is meant to be extended. (Each option is a checkbox and there are 'Move Up' and 'Move Down' buttons to set the order in which the tasks are performed.) I have spent a good deal of time searching the jazz.net net documentation and the forums but have not found anything that would help me get started with this process. Is this even possible? Can anyone point me to documentation that would get me going in the right direction?
Thanks, -Dave |
26 answers
Sure Nick,
I am looking to extend the RTC build process by adding post-build steps. I followed your tutorial and successfully created my build configuration with editor, and placed it in a build template. I'm struggling a bit with getting my build engine participant loaded. I've dropped my build plugin (which uses the buildEngineParticipants extension point) into buildsystem\buildengine\eclipse\plugins and restarted the JBE, but it is not getting picked up. I enabled my build engine and definition to support this participant through the UI, it is just the plugin not getting loaded. From the architecture page, it seems this should be enough. Do I have to drop my build plugin into the Team Server instead? Thanks, Andrew |
No changes to the server are needed for build participants.
Try running JBE with -clean the first time after adding/removing/updating plugins. The runtime caches the list of plugins after the first run; -clean forces it to update. Alternatively, you can delete the contents of the configuration directory, except for config.ini. Also check for log files in the configuration directory, or workspace/.metadata/.log. Running with -debug and -consoleLog can also help with debugging configuration issues. You can also add -console to use the OSGi console to track down dependency issues: use ss to list plugins, and diag <id> to diagnose. |
|
I was kind of fishing for what your extension does, though :-).
|
|
Those debugging tips were useful. I found two problems with my build engine plugin.
1) Unsatisfied dependencies. I fixed these by restructuring my plugins (details later) 2) Disable lazy loading of my build engine plugin. Most of my plugins use "Bundle-ActivationPolicy: lazy" in MANIFEST.MF but this cannot be used in the plugin defining the build engine participant. I restructured my plugins as follows: arf.build.common: Defines my build configuration element, and the build definition template that includes it arf.build.ui: My buildConfigurationElementEditor classes arf.build.engine: My build engine participant I added arf.build.common and arf.build.ui to my client. I added arf.build.common and arf.build.engine to my JBE. The plugins collectively provide another post-build publish option. |
|
Good to hear.
Most of my plugins use "Bundle-ActivationPolicy: lazy" in MANIFEST.MF but this cannot be used in the plugin defining the build engine participant. Why not? This isn't a restriction we impose. Plugins with extension registry info (i.e. a plugin.xml) do however need to be marked as singletons, e.g.:
Since JBE creates the participant through the extension mechanism, it can activate the plugin lazily. |
|
You're correct, the lazy activation option can be used when the plugin is a singleton. Thanks!
|
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.