Here you can find the development related issues when working with the Apache Marmotta source code and/or contributing to it.


The project team uses different mailing lists for internal communication:

Twitter (@ApacheMarmotta) is also used, but more for quick updates of the project and some informal communications.

In addition, the project uses the #apachemarmotta IRC channel at Freenode. Regular meetings are held there; logs are always published and sent to the mailing list to mitigate the barriers of people in different timezones.

Source code

The code is managed using Git, and you access the repository at:


There you would find something similar to the following structure:

|-- build
|-- client
|-- commons
|-- extras
|-- launchers
|-- libraries
|-- loaders
|-- parent
|-- platform
`-- pom.xml


  • build directory contains some tools related with the Maven build system, such as plugins and archetypes.
  • client hosts the different implementations of the client library.
  • commons contains a collection of support modules for Marmotta, adding additional functionality like parsers or writers.
  • extras has been created to store those “extra” configurations that are for various reasons not included in the main distribution.
  • launchers contains different launch configurations for Apache Marmotta (WAR, Installer, etc).
  • libraries agroups some libraries that can also be used independently to build Linked Data applications.
  • loaders provides optimized bulk loaders for some of the backend supported by Marmotta.
  • platform contains the Linked Data Platform implementation of Apache Marmotta.


Apache Maven is used as integrated build system; check out how to build Marmotta from the source code.

Marmotta uses a Gitflow Workflow (read more), depicted by the diagram on the right, which uses the following framework:

  • Instead of a single master branch, we are using two branches to record the history of the project: the master branch stores the official release history, and the develop branch serves as an integration branch for features. The whole project development works around the distinction between these two branches.
  • New features could optionally open feature branches for some topics/issues, which are typically identified with the issue key from our issue tracker (MARMOTTA-XYZ).
  • In addition, maintenance or hotfix branches (maintenance-3.0.x for instance) are also used to quickly patch production releases without interrupting the current development cycle.

The main git repository is being mirrored at GitHub (, from where you could directly send us pull requests with your contributions or patches. Please, referencence an issue from Jira in the title of your pull request.

If you want to contribute documentation, this web site is our main documentation. Due some restriction of the Apache CMS, the code of the web site is available in a separated Subversion repository:



Marmotta continues the versioning structure of LMF. The base code was contributes from LMF 2.6.0, that’s why Marmotta started with version 3.0.0-incubating. Here the list of versions of Marmotta:

Issue tracker

Apache Marmotta uses Jira for tracking bug reports and requests for improvements, new features, and other changes. The issue tracker is available at, and is anonymous readable by everyone. An account is needed to create new issues or to comment on existing issues.

When reporting a new issue, please try to be as descriptive as possible. For instance, the issue summary should be a short and clear statement that indicates the scope of the issue; you are probably being too verbose if you exceed the length of the text field. Use the Environment and Description fields to provide more detailed information. Besides, use the right type and assigned to the corrrect component to allow the project to be more effective on its resolution. See below some additional information and guidelines on creating and managing issues.

Issue type

When creating a new issue, select the issue type based as follows:

Issue type Description
Bug Bug reports are used for cases where Marmotta fails not function as it should (as defined by some documentation). If you are not certain whether the issue you've found is actually a bug, please ask at the mailing list first for help.
New Feature Use a feature request when Marmotta does not have some functionality you need.
Improvement Use an improvement request to suggest improvements to existing features. Typical improvement requests are about updating documentation, increasing stability and performance, simplifying the implementation, or other such changes that make Marmotta better without introducing new features or fixing existing bugs.
Test Use this type when contributing test cases for existing features. Normally test cases should be contributed as a part of the original feature request or as regression tests associated with bug reports, but sometimes you just want to extend test coverage by introducing new test cases. This issue type is for such cases.
Task Used only for issues related to project infrastructure.

Issue priority

Issue priority should be set according to the following:

Issue priority Description
Blocker Legal or other fundamental issue that makes it impossible to release Marmotta code
Critical Major loss of functionality that affects many Marmotta users
Major Important issue that should be resolved soon
Minor Nice to have issues
Trivial Trivial changes that can be applied whenever someone has extra time

Issue workflow

Marmotta issues can transition through a number of states while being processed:

State Description Next states in workflow
Open The issue has just been created In Pogress
In Progress Work has started on the issue Resolved, Open
Resolved The issue has been resolved from the developers point of view. Documentation and Testcases have been created and updated as required. Issue is ready for release. Reopened, Closed
Reopened A resolved issue has been recognized to contain bugs or to be incomplete and thus has been reopened. In Progress, Resolved
Closed Work on this issue has finished and it is included in the release. --

Users generally create issues and provide feedback while work on the issue is in progress. When the developer thinks the issue has been resolved, he resolves the issue. At this point, the user may test the resolution and reopen the issue if it has not really be solved. Otherwise the user may just acknowledge the fix.

Developers transition the issue through the workflow while working on it. When done with the issue, they mark the issue resolved with the appropriate resolution and ask the reporting user to confirm.

Issues are closed once the project against which it has been reported has been released. Issues once closed cannot be opened again. Rather new issues should be created against the new release to have broken implementations fixed or extended.

Development Practices

So far we are not following strick development practices, but for Java coding we heavily base it on the Code Conventions for the Java Programming Language published by Oracle.


When reporting a bug, requesting a feature or propose an improvement, it is a good thing to attach a patch to the issue. This may speed up issue processing and helps you being recognized as a good community member leading to closer involvement with Marmotta.

While there is no exact criteria for becoming a committer, there is a fairly obvious path:

  • For starters, one should be familiar with the Apache Way, especially the part about meritocracy.

  • Second, participate in the mailing lists, help answer questions when you can and do so in a respectful manner. This is often more important than writing amazing code.

  • Third, write code, add patches, stick with them and be patient. Add unit tests and documentation. In general, tackling 3 or 4 decent patches is where the bar is at, but it depends on the state of the project. In the earlier stages of the project, the bar is a bit lower, so it pays to join early!

  • Finally, it is then up to someone to nominate them to the PMC. Typically, one of the existing committers does this by sending an email to the private PMC mailing list and then the PMC votes on it. Nominations often occur internal to the PMC as well.