aint / jblog Goto Github PK

• Why not Spring?

The first reason is that it is a simple project for beginners. Secondly, the performance is very important, because jblog running on a free Java hosting.

• What if my question isn't answered here?

You can get answers to your questions by this email: [email protected]

• JDK 1.6 (in code not using JDK 7 features)
• Git
• Tomcat 7
• Maven 3
• MySQL 5.1
• Hibernate 3 with annotation based configuration
• JSR-303 (Hibernate Validation)
• Servlets as controllers
• JSP for view
• SLF4J + Logback for logging
• Velocity for templates
• TestNG as a testing framework
• Mockito as a mock framework
• H2 Database in-memory database for unit testing DAOs and other database code
• Sonar for managing code quality

Contributions from the community are essential in keeping jblog (any Open Source project really) strong and successful. While we try to keep requirements for contributing to a minimum, there are a few guidelines we ask that you mind.

Firstly the most important part, the branching model that we follows. Our branching model is based on a post on Git branching models by nvie.

In short, the model is explained nicely in this picture:

To make following this model easier we use git-flow which contains high level extensions for this Git branching model. Please start by installing the git-flow extensions as per installation instructions on their project page. There is also a blog post explaining in short how git-flow basics work.

If you're familiar with git and GitHub, here's the short version of what you need to know. Once you fork and clone the jblog code:

• Never, ever, do anything in master branch. The branch develop is the head of development, master is for stable releases!
• Don't develop on the develop branch. Always create a feature branch specific to the issue you're working on. Name it by issue #. For example, if you're working on issue #323, your feature branch should be called iss-323 or issue-323. If you decide to work on another issue, create a new branch for that issue - don't work on both in one branch.
• A single feature branch should represent changes related to a single issue. If you decide to work on another issue, create another feature branch from develop

• Make commits of logical units.
• Commit message convention is "Fixed #number-of-issue. Some description.". Be sure to use the issue number in the commit message. This is how GitHub will pick up the related commits and display them on the GitHub issue.
• Make sure you have added the necessary tests for your changes.
• Run all the tests to assure nothing else was accidentally broken.

• Unix (LF) line endings for all files.
• Eliminate all trailing whitespace.
• The GNU Lesser General Public License version 2.1 MUST be placed at the top of each and every file.
• One blank line should always be used at end all files.
• Make is as simple as possible, but no simpler.

We use the Code Conventions for the Java Programming Language and Code Conventions for the JavaServer Pages Technology with some exceptions.

• The exact construction of the indentation is 4 spaces. NO tabs. It was not easy desigion. We understand that a lot of you like to use tabs, but the fact of the matter is that tab characters cause different interpretation in the spacing of characters in different editors.
• Java source files shouldn't be large, you should try to make them not more than 300 lines.
• No more lines in a method then can be viewed in a single screen without scrolling.
• Javadoc MUST exist on all your methods. Also, if you are working on existing code and there currently isn't a javadoc for that method/class/variable or whatever, then you should contribute and add it. This will improve the project as a whole.
• The max line length is 120 symbols.

• Package names should start of the aint project domain name (aint.github.com), then it should include the name of concrete project (jblog), and after that the module name it resides in. E.g. "com.github.aint.jblog.service".
• Try to avoid circle dependencies between packages.
• Packages shouldn't contain a lot of classes. 100 is too much, but 20-30 is OK.
• Class names should be nouns, in mixed case with the first letter of each internal word capitalized (camel style). E.g. UserDao, not UserDAO.
• Interface and abstract class names shouldn't start with I and A, respectively. E.g. MailService, not IMailService; TextEntity, not ATextEntity.
• If you can't imagine any suitable name for implementation of some interface, name it InterfaceNameImpl.
• If you don't want/can implement some method and leave it an empty, you must throw UnsupportedOperationException in its body.
• JavaDoc should be present for packages, classes, methods, constants.
• All JavaDoc sentences of general description should end up with a dot. Exceptions: param, return, throw - they may not contain dots, but only if they consist of one sentence; if two or more - you have to put dots after each sentence.
• Code coverage tests not less than 70%

• Use underscore to separate words in key names, not camel case. E.g. welcome_message = Hi.
• Use dots to separate places where the key is used. E.g. header.label.welcome_message = Hi.

• Use 2 spaces for indentation.
• Tags like this <tag attribute="value" /> should contain a space between last attribute and slash.

• Use 4 spaces for indentation.
• Avoid JSP scriptlets and declarations.
• Tags like this <tag attribute="value" /> should contain a space between last attribute and slash.
• JSP files or fragment files should contain a server side style comment with Author(s) and Description elements.