Difference between revisions of "PKI Developers"

From Dogtag
Jump to: navigation, search
m (Eclipse Project Set Up)
m (Eclipse Project Set Up)
Line 70: Line 70:
== Eclipse Project Set Up ==
== 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
See [[PKI Eclipse]].
* 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 [[PKI Eclipse]] page.
== Standards and Guidelines ==
== Standards and Guidelines ==

Revision as of 03:47, 7 March 2018


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.

To browse through our backlog of development tickets, access the Dogtag Trac instance.

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

The current source code is stored in a GitHub repository.

GitHub Repository

To create a new local repository from GitHub:

$ git clone git@github.com:dogtagpki/pki.git

To switch an existing local repository (i.e. preserving local branches) to GitHub, execute the following commands in the local repository's folder.

To check the current repository:

$ git config remote.origin.url

To switch the repository to GitHub:

$ git config remote.origin.url git@github.com:dogtagpki/pki.git

To verify the switch:

$ git fetch

Fedora Git Repository

Previously the source code was stored in a Fedora git repository.

To browse the repository, go to https://github.com/dogtagpki/pki.git/.

To checkout anonymously (read-only):

$ git clone git://github.com/dogtagpki/pki.git

To checkout as a Fedora user (with write access):

$ git clone ssh://username@github.com/dogtagpki/pki.git

Fedora Subversion Repository

Previously the source code was stored in a Fedora subversion repository.

To browse the repository, go to https://svn.fedorahosted.org/svn/pki/.

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

Eclipse Project Set Up

See PKI Eclipse.

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.

For some quick instructions on how to build Dogtag 10, see Building Dogtag 10.

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.


Javadocs (for the documented versions) are available at On-line Dogtag Javadocs.


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.