Apache Zest™ codebase is hosted at the Apache Software Foundation and follow the git-flow development model.
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 Zest™ differs slightly from the regular project, due to our specific needs and style of development. the main differences are;
Apache Zest™ uses the
developbranch for the day to day changes to the project. The
masterbranch is used for the latest releases. See below about the 'Git Development Model'.
- Apache Zest™ 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 Zest™ 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;
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 https://git-wip-us.apache.org/repos/asf/zest-sandbox.git
The Apache Zest™ (Java Edition) is the main development codebase, and to start working with it you simply clone it;
git clone https://git-wip-us.apache.org/repos/asf/zest-java.git
The two repositories can be browsed on the mirrors on the ASF Github organization;
Apache Zest™ has a 3 level committer access system. The groups are "Core", "Platform" and "Community" and the roles are very clear.
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 Zest™ the best platform out there, and not listen in on the voices of features and changes that derails the vision and principles of Apache Zest™.
Over the course of Apache Zest™'s history, there have been several occasions where brilliant developers got caught up in 'feature improvements' which went against the fibers of Apache Zest™ 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 Zest™, 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 Zest™, the philosophy that drives Apache Zest™ and prudence in working on highly sensitive codebases. In return we will strive for making the Apache Zest™ 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 Zest™ Runtime, stable over time and not bloating with unnecessary features. Thanks for understanding.
These form the work force of Apache Zest™. They will work on the Extensions and Libraries, which eventually will make Apache Zest™ the most efficient way of programming in Java.
Any person who is interested in helping out with Apache Zest™ 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 Zest™'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 firstname.lastname@example.org 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.
Apache Zest™ 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
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 Zest™ (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; http://nvie.com/posts/a-successful-git-branching-model/
The most important part of that excellent article can be found below.
Git Branching Model used at Apache Zest™
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;
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 Zest™ 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.
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; https://github.com/nvie/gitflow
What happened to the
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
branch, never directly from
How do I do my first commit?
We strongly encourage people to read up on Git basics at git-scm.com.
But some basic commands are discussed here.
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.
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
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
feature/my_new_feature_branch only. This is very handy if one forgets to create and move
to a branch before modifying the
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; https://help.github.com/articles/using-pull-requests