The TFS SDK for Java package contains documentation, samples, and redistributable files that help you extend Team Explorer Everywhere clients and access Team Foundation features from Java applications. The SDK for Java requires Java 5 or later.
There are multiple ways to develop software with this SDK. Decide which scenario below best fits your situation and read the corresponding section below.
You want to access Team Foundation features from a Java application where Team Explorer Everywhere is not installed.
In this scenario you add the redistributable JAR and native libraries to your application, then use classes in the client object model to interact with a Team Foundation Server. High-level classes locate services, perform authentication, and expose version control, work item, and build features to your application. You can customize the behavior of some of the client object model classes.
You want to use Eclipse extension points and other APIs to extend Team Explorer Everywhere or use some of its features in your own Eclipse-based application.
You want to enforce custom rules before files are checked into Team Foundation Server from Team Explorer Everywhere or the Team Explorer Everywhere Cross-platform Command-line Client.
A list of some of the items inside the SDK for Java:
docs | |
javadoc | API documentation for the SDK classes in HTML format |
redist | |
lib | Java archives containing client object model classes and resources |
native | Native library files required by client object model |
notice.html | Third-party software notices |
redist.txt | A list of files you may redistribute under the terms of the software license |
samples | Code samples |
license.html | Software license terms |
This scenario applies when developing an application that uses Team Foundation features but does not run in the Eclipse environment. The SDK for Java client object model offers features similar to the Team Foundation client object model for .NET and Visual Studio.
Client object model classes do not provide graphical interfaces to Team Foundation features. They do not depend on packages such as Swing or SWT/Eclipse, but may be used safely in programs that use them.
The client object model is packaged as one JAR file and a collection of native code libraries. The native libraries are required by the client object model classes to perform tasks such as single sign-on authentication, filesystem attribute modification, console measurement, and reading information from the process's environment.
Follow these steps to get started using the client object model:
To define a Java system property, use the -D option when you start the Java virtual machine. For example, on Unix operating systems:
java -D"com.microsoft.tfs.jni.native.base-directory=/home/username/YourApplication/native"
and on Windows:
java.exe -D"com.microsoft.tfs.jni.native.base-directory=C:\Users\Username\YourApplication\native"
When you deploy the native libraries with your application you must preserve the file and directory structure inside the native directory.
The com.microsoft.tfs.sdk.samples.snippets project in the samples directory contains source code for several sample programs that each perform a basic task with the client object model.
You can import this project into the Eclipse IDE or build it manually with Apache Ant using the build.xml file. See the readme.txt file in the sample project for manual build instructions.
The com.microsoft.tfs.sdk.samples.console project in the samples directory contains source code for several applications that use the client object model in advanced ways. Read these samples to learn about topics such as:
You can import this project into the Eclipse IDE or build it manually with Apache Ant using the build.xml file. See the readme.txt file in the sample project for manual build instructions.
Extending the plug-in for Eclipse is done with Eclipse extension points. Use Eclipse's plug-in artifact discovery features to find public extension points in the Team Explorer Everywhere plug-ins. Client object model classes and features are available in this scenario because the packages are re-exported from the Team Explorer Everywhere plug-ins. Customization of the connection process through the client object model is not supported because the plug-in for Eclipse requires specific connection behavior.
The com.microsoft.tfs.sdk.samples.witcontrols project in the samples directory adds custom work item control types to the Team Explorer Everywhere work item editor.
Import this project into the Eclipse IDE where the Team Explorer Everywhere plug-in for Eclipse is installed. See the readme.html file in the sample project for help using this sample.
You can write custom check-in policies in Java and deploy them where Team Explorer Everywhere clients are installed.
The com.microsoft.tfs.sdk.samples.checkinpolicy project in the samples directory is an implementation of a custom check-in policy that works with both the graphical Team Explorer Everywhere and with the non-graphical Cross-platform Command-line Client programs.
Import this project into the Eclipse IDE where the Team Explorer Everywhere plug-in for Eclipse is installed. See the readme.html file in the sample project for help using this sample.
Sample projects which are not Eclipse plug-in projects require manual configuration before they will build and run in Eclipse. If one of the samples you imported into your workspace does not build or run, follow the steps in this section.
Some samples cannot be compiled until the redistributable JAR is added to the project's build path. To add the JAR to the build path:
The sample project should now compile without errors.
To debug and run sample projects which are not plug-in projects, you must edit your debug or run configuration to set the system property the native library loader users. If you do not know how to create and edit debug or run configurations, refer to the Eclipse documentation. To set the system property:
Now the native libraries can be loaded by the client object model when you debug or run your application.