Difference between revisions of "PKI Developers"

From Dogtag
Jump to: navigation, search
(Source Code)
(Source Code)
Line 28: Line 28:
** [http://pki.fedoraproject.org/pki/javadocs/pki-util-9.0.9/usr/share/javadoc/pki-util-9.0.9/ pki-util 9.0.9]
** [http://pki.fedoraproject.org/pki/javadocs/pki-util-9.0.9/usr/share/javadoc/pki-util-9.0.9/ pki-util 9.0.9]
* '''Dogtag 10.0.0 (Alpha)'''
* '''Dogtag 10.0.0 (Alpha)'''
** [http://pki.fedoraproject.org/pki/javadocs/jss-4.2.6-17/usr/share/javadoc/jss-4.2.6 jss 4.2.6-17]
** [http://pki.fedoraproject.org/pki/javadocs/jss-4.2.6-21/usr/share/javadoc/jss-4.2.6 jss 4.2.6-21]
** [http://pki.fedoraproject.org/pki/javadocs/pki-common-10.0.0-0.10.a1/usr/share/javadoc/pki-common-10.0.0-0.10.a1/ pki-common 10.0.0-0.10.a1]
** [http://pki.fedoraproject.org/pki/javadocs/pki-common-10.0.0-0.10.a1/usr/share/javadoc/pki-common-10.0.0-0.10.a1/ pki-common 10.0.0-0.10.a1]
** [http://pki.fedoraproject.org/pki/javadocs/pki-java-tools-10.0.0-0.10.a1/usr/share/javadoc/pki-java-tools-10.0.0-0.10.a1/ pki-java-tools 10.0.0-0.10.a1]
** [http://pki.fedoraproject.org/pki/javadocs/pki-java-tools-10.0.0-0.10.a1/usr/share/javadoc/pki-java-tools-10.0.0-0.10.a1/ pki-java-tools 10.0.0-0.10.a1]

Revision as of 20:45, 27 April 2012


Developers should check out the building guide to see how to build the Dogtag Certificate System from source. Then, you can choose to work on fixing bugs, adding new features, or improving the documentation. For other ideas, see our list on ways to contribute.

Alternatively, developers can jump directly to instructions on installing any of the various subsystems.

If a developer wants to contribute code to the project, look at the contributions page. It contains information on the process required to be able to submit patches that will be accepted. From a more technical standpoint, check out the appropriate coding style guide before submitting a patch.

Also, take some time to review the license. To understand the inner workings of the servers, the developers can read the architecture section.

Source Code

Current Dogtag development is being done in a Git repository. This is a recent transition from SVN, so the repositories are split based on the Dogtag version. The breakdown is as follows:

  • Post-9.0 versions of Dogtag - Git
  • Dogtag 9.0 and earlier - SVN

Our git repository is located on fedorahosted.org here. You can use one of the following commands to clone our Git repository (use the "ssh://" version of the clone command if you are authenticating with a Fedora account, otherwise use the anonymous "git://" version):

git clone git://git.fedorahosted.org/git/pki.git
git clone ssh://git.fedorahosted.org/git/pki.git

To check out older Dogtag versions from SVN see our Subversion instructions page. Additionally, you can download the source RPM for released versions of Dogtag from the yum repositories.

Javadocs (for the documented versions) are available on-line at the following locations:

Eclipse Project Set Up

It is recommended that you use Eclipse for Dogtag development. The source tree is set up such that you can easily import it as a project into Eclipse. Aside from being a nice IDE for Java development, Eclipse is able to ensure that your code meets some of our code formatting standards. To import Dogtag as a project in Eclipse, perform the following steps:

  • Clone the pki Git repository
  • In Eclipse, choose File->Import...
  • In the Import dialog box, select General->Existing Projects into Workspace, then click the Next button
  • Click the Browse... button and select the top level pki directory that you cloned from Git as your root directory.
  • Ensure that the pki project is listed and checked in your Projects list, then click the Finish button.

At this point, Dogtag will be imported as a project in Eclipse. You will likely have many build errors at this point due to missing build dependencies. It is best to consult the pki-common specfile in the source tree to see what the build dependencies are, then install them with yum. A simple way of doing this is to run the following command from within the pki directory that you cloned from Git:

yum install `awk '/^BuildRequires:/ {print $2}' ./specs/pki-core.spec`

For more details on using Eclipse for Dogtag development, see our Eclipse page.

Standards and Guidelines

Coding standards and guidelines are available for each language comprising the Dogtag Certificate System.

Patch Review Process - how to have a patch reviewed before pushing it to our source repository.

Additionally, the Dogtag Certificate System follows the Filesystem Hierarchy Standard (FHS) packaging standard.


To learn how to build Dogtag Certificate System as a developer, see Building the Dogtag Certificate System.

The Dogtag Certificate System currently does not have nightly builds and tinderbox builds.

A tinderbox is basically a continuous build cycle: pull SVN, build, report, repeat.

This is very useful when a lot of check-ins are happening at once, since feedback will be provided fairly quickly when something breaks.


To learn how to install and configure a PKI instance, see the PKI Installation Guide.

Certificate System Plug-ins

It is possible to write plug-ins that extend the functionality of various aspects of the Certificate System. The various plug-in tutorials listed below contain information about a specific API and the scope of its functionality.


Not a programmer? No problem. Contributors can help by finding new bugs, verifying existing bugs, polishing documentation, and generally improving the quality of the various subsystems.

A good way to contribute to improving the quality of a subsystem would be to add automated tests for each of the features. Developers and contributors to the Dogtag Certificate System Project are encouraged to write unit tests for any new features, updates, and bug fixes being contributed. Where possible, the tests should be data driven. This allows for greater numbers of test cases, covering more of the features under testing, to be written with minimal effort. We suggest that tests be written in a scripting language such as bash, Perl ( Perl::Test ), or Python for ease of maintenance.