After the first 3 years of depending on the OPS4J project, then 5 years on Github, the Qi4j community finally moved to the Apache Software Foundation (ASF) on March 2015. The codebase history is kept in Git repositories, mirrored to the ASF Github organization. This should simplify the learning, as not only does developers have plenty of experience with Git, and tools around it, but also there are endless amount of documentation and user forums to support each individual, off-loading some of that burden from us. This page only contain rudimentary information.

Public Access Repository

Apache Polygene™ differs slightly from the regular project, due to our specific needs and style of development. the main differences are;

  • Apache Polygene™ uses the develop branch for the day to day changes to the project. The master branch is used for the latest releases. See below about the 'Git Development Model'.
  • Apache Polygene™ uses a social contract to limit access to different areas of the project, instead of ACLs. The driving point is to relax the contribution criteria in less critical parts, to encourage a wider participation that otherwise would not be possible.

Apache Polygene™ used to have many repositories to accommodate for the authorization issue above, but eventually settled with a single Git repository, and now only have 2 repositories;

  • polygene-java
  • polygene-sandbox

The sandbox is where experimental code goes, and modules that are not ready to be shipped, or can not be shipped due to licensing restrictions (e.g. Oracle doesn't provide Coherence as automatic download for our testing, so can't really ship the coherence extension). The sandbox is a normal Git repository available to clone as; git clone

The Apache Polygene™ (Java Edition) is the main development codebase, and to start working with it you simply clone it; git clone

Web Access

The two repositories can be browsed on the mirrors on the ASF Github organization;

Committer Access

Apache Polygene™ has a 3 level committer access system. The groups are "Core", "Platform" and "Community" and the roles are very clear.

Core Developers

These are the guardians and stewards of the core technology and ultimate rulers of what is going on. The hope is that a small group of benevolent dictators will manage to make Apache Polygene™ the best platform out there, and not listen in on the voices of features and changes that derails the vision and principles of Apache Polygene™.

Over the course of Apache Polygene™'s history, there have been several occasions where brilliant developers got caught up in 'feature improvements' which went against the fibers of Apache Polygene™ philosophy and technological direction. IF we would have had an 'open door' policy to changes in Core, these 'improvements' would have degraded the excellence of Apache Polygene™, and we are not likely to invite anyone to the Core Developer team, unless the individual shows remarkable understanding of the inner workings of Apache Polygene™, the philosophy that drives Apache Polygene™ and prudence in working on highly sensitive codebases. In return we will strive for making the Apache Polygene™ Core as small as possible, having most features in libraries and extensions. We welcome any suggestions that breaks out pluggable functionality.

We apologize in advance if this comes across as elitist, but the purpose is to ensure a high quality Apache Polygene™ Runtime, stable over time and not bloating with unnecessary features. Thanks for understanding.

Platform Developers

These form the work force of Apache Polygene™. They will work on the Extensions and Libraries, which eventually will make Apache Polygene™ the most efficient way of programming in Java.

Community Developers

Any person who is interested in helping out with Apache Polygene™ will be granted access to Sandbox, Tests, IDE support, Tutorials, Samples, HowTos, documentation and other (i.e. not Core, Libraries and Extensions). This will gauge their abilities and commitment to the project, with an aim to make them Platform Developers.


Of course, Git's distributed nature also allows anyone to fork our repositories, and have the patches find their way back to Apache Polygene™'s official repository. And GitHub's pull-request system makes the management of this a lot easier, and something that we encourage.

How to Join?

To become a Community Developer, just subscribe to the mailing list and participate, nothing more than a desire to help is required.

Community Developers who are active and keep contributing feedback, patches and/or documentation are likely to be invited as Platform Developers, who has access to everything except the delicate Core, which we intend to keep a lot more clean and stable than a free-for-all repository has a tendency to become over time.

Commit Policy

Apache Polygene™ generally uses a Commit-Then-Review policy on most changes. This allows a reasonable high velocity of development.

Commits are visible in Git history and at GitHub. Active contributors should review all incoming commits to ensure quality of contributions and avoidance of mistakes.

For any given commit, any member of the community may raise concern(s) on the dev@ mailing list. We encourage as many people as possible to review the changes that are occurring. "With enough eyeballs every bug is shallow." wrote Eric S. Raymond in "The Cathedral and The Bazaar" about open source.

Special rules applies to changes in the Core Test suite. Adding new tests are CTR, but modifying existing tests, either to accommodate for code changes in Core or to tighten the constraints of them, MUST be discussed on the dev@ mailing list, prior to committing them to the 'develop' branch. We recommend that a different branch is used for these changes, unless simply codesnippets are pasted to mail. This exists to ensure that we have a stable evolution of Apache Polygene™ (Java Edition) Runtime, and no surprises will occur in existing applications with new versions.

Git Development Model

Courtesy of Vincent Driessen, we borrowed the Git branching model from this web page;

The most important part of that excellent article can be found below.

Git Branching Model used at Apache Polygene™

It looks more complicated than it is. Here are the guidelines;

  • Never commit to the 'master' branch while developing!!
  • The 'develop' branch is the equivalent of trunk in subversion.
  • Any changes that are not trivial, start a feature branch.
  • The following names are reserved for not feature branches; master, develop, hotfix/*, release/*

Day-to-day development revolves around the develop branch and it is this branch that you typically clone from our repository if you intend to contribute to Apache Polygene™ itself. If you create a new feature, or make some larger piece of refactoring, then please create a 'feature branch' (see article for details).

Please try to remember the --no-fast-forward option during merge, so the feature branch is preserved in one piece and can be rolled back easily if needed.

The release/* and hotfix/* branches are for release management only, and doesn't affect most contributors from a commit perspective. Release Managers - Check the article for the details.

For convenience you should install and use the gitflow git extension that implement this branching model by adding git commands. See the gitflow web page;

What happened to the master branch?

In case you missed it above, check the model that we used for development. The intent is that the master branch is always in a good state and the HEAD is at a formal release (and has a tag for that).

Patches only enters the 'master' branch either from a hotfix/* or a release/* branch, never directly from develop or feature/* branches.

How do I do my first commit?

We strongly encourage people to read up on Git basics at

But some basic commands are discussed here.

git status

shows you what has not been committed.

git add <filename>

all files(!) must be added. Directories are not considered and generally ignored. You can add with wildcards, even if some files have already been added.

git commit -a -m "<some message>"

This commits the current branch to the local repository. The -a means commit all files, and not only the ones that are explicitly mentioned on this command. The message should be informative as it will follow the patch 'forever'.

git push origin develop

Pushes the local commits back to the origin, i.e. the place the clone came from, or to the location that you have moved the origin to be instead (see above).

git pull origin develop

Pulls/downloads the changes of the develop branch from the origin of your local clone. In subversion terms, this roughly corresponds to a svn update of the trunk.

git branch

Shows which branch we are working on.

git checkout -b feature/my_new_feature_branch

Creates a new branch with the given name, unless one already exist, and make the 'current' branch to be the feature/my_new_feature_branch.

When you do a checkout of a branch, the local changes in the current branch that are not committed are not lost, but are also 'moved along' to the new branch. And if those changes are then committed in the feature/my_new_feature_branch and one switch back the changes are not there, now sitting in the feature/my_new_feature_branch only. This is very handy if one forgets to create and move to a branch before modifying the develop branch.

Using Github Pull Requests

Pull requests let you tell others about changes you've pushed to a GitHub repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Github's guide to Pull Requests walks through the process of sending a hypothetical pull request and using the various code review and management tools to take the change to completion. This guide can be found here; That article assume that we have direct control of the GitHub repository, but we don't. Instead we need to pull the Pull Request to our local machine, merge it in and then push it back via the Apache GIT server.

The infrastructure team is working on Pull Request support on the GitHub servers directly, but it is not available by default yet.

Example, for pull request 42, you would need to do the following;

# You need to have a "remote" defined in your git configuration
# This is only needed once
git remote add github

# Fetch the commit  
git fetch github pull/42/head:merge-pr-42

# These next two steps are optional.
# If you choose to rebase, then the Pull Request is not automatically closed.
git checkout merge-pr-42
git rebase develop

# Check out 'develop' branch
git checkout develop

# Merge the PR
git merge merge-pr-42

# Remove the PR branch
git branch -D merge-pr-42

# Push the result
git push origin develop