Developing a Custom Check-in Policy using TFS 11 SDK for Java

Posted by: Subodh Sohoni , on 4/14/2012, in Category VSTS & TFS (Azure DevOps)
Views: 115158
Abstract: In this article, I will take you through the process of creating and deploying a custom check-in policy using TFS SDK 11 for Java.

In this article, I will take you through the process of creating and deploying a check-in policy using TFS SDK 11 for Java. This SDK is at a Beta phase so some changes by the time of RTM cannot be ruled out. You can download TFS SDK 11 for Java from the same page where Team Explorer Everywhere 11 is available

Check-in policy is one of the strong points of TFS source control. It checks for some condition being met at the time of check-in and then based upon the success of that condition check, it either allows or disallows the check-in from going ahead. Microsoft provides some standard check-in policies in the box of TFS but the conditions that an organization may want to check can be totally different. It is possible to create and deploy custom check-in policies using the TFS APIs that are published by Microsoft. In TFS SDK 11 for Java, there are certain classes that we can use to create such check-in policies. I assume that you have downloaded and extracted the TFS SDK 11 for Java from the URL provided earlier in the article.


Check-in policy that works with Team Explorer Everywhere 11 is a plug-in into Eclipse. Like any plug-in, a custom check-in policy can be developed using Eclipse for plug-in development (only). We can download such a version of Eclipse, that is called the ‘Eclipse for RCP and RAP Developers’ from the page . Once downloaded, the package can be extracted at a convenient location. I extracted it at D:\Java so that a folder D:\Java\eclipse-rcp-indigo-SR1-win32-x86_64 was created. We can create and test the plugin using this version of Eclipse. Now on my machine, I have two Eclipse installations. First one is for regular Java applications development and another one for Eclipse Plugin development. I installed Team Explorer Everywhere 11 (Beta) on both the instances of Eclipse.

Let me now show you what is there in TFS SDK 11. It contains folders of Documentation (Javadocs), Redistributable components (a JAR named and some native components) and some sample projects to learn how to code using this SDK. We will use the redistributable component for creating the check-in policy.

For understanding the process of creation and deployment of check-in policy, we will take up a case. The case that I am going to take up is of Code Review. Microsoft has implemented code review workflow as standard workflow in TFS using Code Review Request and Code Review Response work items. Unfortunately, at the least in Beta of the TFS 11, that workflow is not available in Team Explorer Everywhere 11. We will bypass those work items and create another work item of the type Code Review. Whenever a developer completes the creation of modification of some code (s)he will put it in a shelveset and create an instance of code review work item and assign it to a reviewer. The name of the shelveset is part of the code review work item data. Reviewer will do the review and if the code is found to be acceptable, will set the status of the code review work item to ‘Approved’. What the check-in policy will do is to check that every check-in has an associated Code Review work item with the status ‘Approved’. If it is not so, it will not allow the check-in from going through.

Let me now develop such a check-in policy and I will take you through the steps as I perform them on my machine.

I have now opened Eclipse for Plugin Development. While doing so, I created a workspace at “D:\Users\Subodh\Workspace for plugins”.


If you are using the latest Eclipse (Indigo), take care that you are also using the JVM version later than 1.6.0_17. Eclipse opens in the perspective of Plugin Development which has a plugins view.

Now I am creating a new project of the type Plugin Project.


In the New Plugin Project creation wizard, I have provided the name com.ssgs.tfs.policies.codereview.


On the next page of the wizard, I removed the checkboxes against the options to create activator and UI Contribution.

On the next page, I clicked Finish button without accepting any template. It created the project and opened the Overview (of various properties of project) page.


Now I wanted to add the JAR that is provided as a base by Microsoft in the TFS SDK 11 for Java. I right clicked the project name and selected Build Path – Add External Archives.


I browsed to the Redist – Lib folder under the TFS SDK 11 folder and added the JAR named as a Referenced Library. I also copied ‘native’ folder from redist folder of TFS SDK 11 to the project folder. This folder is required to do debugging of the plugin that we develop.


Now I am ready to configure the Plugin so that it has all the necessary dependencies and references setup. I opened the META-INF\MANIFEST.MF


It has many tabs that we need to configure.

On the Overview tab, I just checked that the Java Runtime Environment is set to my machine’s JRE.


On the dependencies tab I set the required plugins to org.eclipse.core.runtime and I knew this because I had seen it in the sample of the custom check-in policy that is provided in TFS SDK 11 for Java.


I also imported the packages org.eclipse.jface.dialogs, org.eclipse.swt and org.eclipse.swt.widgets, again as is done in the sample.

On the Extension tab I selected the Extension Point that is provided by Microsoft,


It had identified the typeID and class with some standard names that I changed to com.ssgs.tfs.policies.codereview.CodeReviewCheckinPolicyInstance and com.ssgs.tfs.policies.codereview.CodeReviewCheckinPolicyClass respectively. It immediately also changed the name of the Extension Point in the left hand side list


In the plugin.xml, these class and type id are reflected correctly but since this class does not exist presently, it shows a warning with a helper sign to create that class


New Class wizard started. All the necessary information was filled up so I clicked on Finish button.


It created a new class that implements the PolicyInstance interface and all the method stubs that need to be overridden. The First code change I did was to change that implementation interface so that my class now extended PolicyBase class instead of implementing the PolicyInstance interface. PolicyBase has some additional methods like getPendingChanges that I want to use later on.


I started the coding with creating a local static variable that will provide details of the PolicyType.

private final static PolicyType TYPE = new PolicyType(               
"Code Review Check-in Policy",
"Disallows check-in if Code Review work item with approved state is not associated with the check-in",
"This check-in policy forces developers to get their code reviewed from experts before it can be checked in. " +
"It checks for associated work item of the type Code Review that has state of approved.",
"Download the check-in policy package and install it in your Eclipse");

Then I set getPolicyType method to return this policy type


I set the constructor to call the constructor of super class. I also did set the properties of CanEdit and Edit to false and set the displayHelp and activate methods to show the appropriate messages. Now I came to the main method of the class and that is ‘evaluate’ method. In the code of this evaluate method, I checked that the PendingChange has an associated work item of the type ‘Code Review’ and the state of that work item is not ‘Not Approved’. This is the code of that all-important evaluate method:

public PolicyFailure[] evaluate(PolicyContext context)
       throws PolicyEvaluationCancelledException {
final PendingCheckin pc =  getPendingCheckin();
final List<PolicyFailure> failures = new ArrayList<PolicyFailure>();

final WorkItemCheckinInfo[] AssociatedWorkItems = pc.getWorkItems().getCheckedWorkItems();
WorkItem AssociatedCodeReview = null;
String failureReason = "";
for (int i=0; i<AssociatedWorkItems.length; i++) {
    AssociatedCodeReview = AssociatedWorkItems[i].getWorkItem();
    if (AssociatedCodeReview.getType().getName() == "Code Review")
    { break; }
if (AssociatedCodeReview != null) {
    if (AssociatedCodeReview.getFields().getField("System.State").getValue().toString().equals("Not Approved"))
failureReason = "Code Review Work Item associated but that is not approved by expert";
         failures.add(new PolicyFailure(failureReason, this));
else {
    failureReason = "Code Review Work Item not associated";
    failures.add(new PolicyFailure(failureReason, this));
return failures.toArray(new PolicyFailure[failures.size()]);                     

and that’s it!  

Summary: In this article I have shown you, how to create and code a check-in policy using TFS SDK 11 for Java. In the next article I will carry this forward to run / debug it using Eclipse and then deploy it on the developers machine.

The entire source code of this article can be downloaded over here





This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+


Subodh is a Trainer and consultant on Azure DevOps and Scrum. He has an experience of over 33 years in team management, training, consulting, sales, production, software development and deployment. He is an engineer from Pune University and has done his post-graduation from IIT, Madras. He is a Microsoft Most Valuable Professional (MVP) - Developer Technologies (Azure DevOps), Microsoft Certified Trainer (MCT), Microsoft Certified Azure DevOps Engineer Expert, Professional Scrum Developer and Professional Scrum Master (II). He has conducted more than 300 corporate trainings on Microsoft technologies in India, USA, Malaysia, Australia, New Zealand, Singapore, UAE, Philippines and Sri Lanka. He has also completed over 50 consulting assignments - some of which included entire Azure DevOps implementation for the organizations.

He has authored more than 85 tutorials on Azure DevOps, Scrum, TFS and VS ALM which are published on is a regular speaker at Microsoft events including Partner Leadership Conclave.You can connect with him on LinkedIn .

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by Shaw Terwilliger on Thursday, May 24, 2012 9:37 AM
This is a very nice tutorial!  I do have one suggestion.  Instead of copying the SDK JAR and "native" directory into your plug-in project, you can simply take a plug-in dependency on the* plug-ins you need.  These plug-ins will provide all the types you need to implement a policy, and your policy plug-in will be using the actual product plug-ins the user has installed (including bug fixes in updates the user has installed).

The sample policy project included with the SDK (samples/ has dependencies set up in this way.
Comment posted by Subodh Sohoni on Saturday, May 26, 2012 8:05 AM
Hi Shaw,
That is an excellent suggestion!
Being newby in Java, I did not get that when I wrote the article. I just experimented and put forward whatever that came to my mind and worked.
Thank you!