Creating custom Pre-Build and Post-Build options

Glad to hear. When doing plug-in development, I recommend running with -clean -debug -consoleLog and maybe -console until things stabilize.

-clean clears out the plugin deployment and registry caches

-debug can give more info in the error log around plug-in dependency issues

-consoleLog routes the error log to the console

-console gives you the OSGi console, which can be helpful for diagnosing plug-in dependency and activation issues (enter help for a list of commands, and check out the ss and diag commands especially)

Thanks for the advice I will certainly use those options going forward.

I have also successfully implemented step 4 so I have a complete working test example of how to extend the build. I do however have one more question for you. How do you envision customers like myself extending the pre and post build processes? Right now I am hacking together some jars with my edited plugin.xml files and class files. Is there a better way to do this? Can I use some eclipse plugin magic to create a new plugin to add these features? (I have some plugin development experience, but it is limited.) I love the fact that I can extend RTC in this way, but the way I'm doing it now is a tedious manual process.

Thanks,
-Dave

I just added an entry to the Build FAQ about using PDE Build. The instructions need to be updated (the example was done against 1.0) but the process is the same, so if you have plug-in development experience you should be able to make sense of it.

https://jazz.net/wiki/bin/view/Main/BuildFAQ#PdeBuild

If you get stuck, just post here.

Also, rather than manually knitting together jars, from the IDE you can use File > Export > Plug-in Development > Deployable plug-ins and fragments.

Both this and PDE Build use the build.properties file to drive what goes into the built plugins.

Hi Nick,

Thanks for your response.

Could you clarify why you want to add Jazz SCM to the Generic template? Normally the Generic template is used only when the build is driven externally, e.g. from an Ant script, in which case the script uses the teamAccept and teamFetch Ant tasks to do the SCM work.

If we were to add Jazz SCM to the Generic template, then it could do the SCM work for you, but it then has no way to do the rest of the build.

The background is that I'm writing a new build engine. Like the generic template, I'm hoping it can drive the build too. I've almost got it to work completely so that when I define a build with the generic template it can see build requests, do a checkout from a defined workspace (defined in my build engine that is) and then update Jazz with the result.

What I don't want to lose out on however is the personal builds and for that I need to have the Jazz SCM pre build step. I had a look at the info in this post and it seemed that the easiest way to do this would be to extend the Generic template. perhaps not. Would it be as simple to take the generic template, copy it, add the Jazz SCM pre build step and then deploy as an all-new, additional Build Definition Template option - "Andrew's Build Template" for example?

Hope this makes sense.

Cheers, Andrew

> Would it be as simple to take the generic template, copy it, add the Jazz SCM pre build step and then deploy as an all-new, additional Build Definition Template

Yes, that would work. Unfortunately templates are not currently extensible (i.e. to add new configurations after-the-fact), but I think they should be.

> Would it be as simple to take the generic template, copy it, add the Jazz SCM pre build step and then deploy as an all-new, additional Build Definition Template

Yes, that would work. Unfortunately templates are not currently extensible (i.e. to add new configurations after-the-fact), but I think they should be.

Thanks Nick,

No worries. I've a little PDE experience so what you''ve posted here should help me on my way. This would then let my Hudson plugin get access to the build request type and workspace name right? That should mean I could have "Personal Build" support. I really like that so its something I'm looking to implement.

You're right though, it would be nice to extend existing ones ;-)

Regs, Andrew

As long as Hudson lets you change certain properties at the time of request, I don't see any reason why you couldn't support personal builds. You just need to set the right property for the build workspace (as discussed previously) in newOrModifiedBuildProperties, and set personalBuild to true in the call to IBuildRequestService.requestBuild, whose signature is:

    public IBuildRequest requestBuild(IBuildDefinitionHandle buildDefinitionHandle,

            IBuildProperty[] newOrModifiedBuildProperties, IBuildProperty[] deletedBuildProperties,

            boolean allowDuplicateRequests, boolean personalBuild, IProgressMonitor progressMonitor)

            throws TeamRepositoryException, IllegalArgumentException;

Not sure how you were thinking of letting the user specify the build workspace though. It could be done just by name, though there's no guarantee of uniqueness on workspace names. Or you could bring up a workspace picker, though that would currently require using REST interfaces that are internal.

Nick,

Thanks for the great tutorial on extending the build process. I suggest you promote this to something in the Articles or Library section so it is easier to find.

Good idea, I should at least capture it as a wiki page. Are you extending Build? Care to share?