Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/idempiere/idempiere/llms.txt

Use this file to discover all available pages before exploring further.

iDempiere follows specific coding conventions and best practices to maintain code quality and consistency. Before contributing code, please review these standards.

Essential Resources

Contributing to Trunk

Comprehensive guide on coding conventions, guidelines, and benchmarks

Fork and Branch Workflow

Detailed explanation of the Git workflow for contributions
Before integrating any code change, please read the Contributing to iDempiere’s core guide to know more about coding conventions, guidelines and benchmarks.

Commit Message Format

All commits must follow the iDempiere standard commit message format:
IDEMPIERE-[####] [Ticket Description]

Examples

git commit -m "IDEMPIERE-1234 Fix tax calculation for EU countries"
git commit -m "IDEMPIERE-5678 Add support for custom payment methods"
git commit -m "IDEMPIERE-9012 Improve performance of inventory queries"
The ticket number should correspond to a JIRA issue at https://idempiere.atlassian.net

Java Code Standards

iDempiere is primarily written in Java. Follow these conventions:

File Headers

All Java files should include the standard iDempiere license header:
/***********************************************************************
 * This file is part of iDempiere ERP Open Source                      *
 * http://www.idempiere.org                                            *
 *                                                                     *
 * Copyright (C) Contributors                                          *
 *                                                                     *
 * This program is free software; you can redistribute it and/or       *
 * modify it under the terms of the GNU General Public License         *
 * as published by the Free Software Foundation; either version 2      *
 * of the License, or (at your option) any later version.              *
 *                                                                     *
 * This program is distributed in the hope that it will be useful,     *
 * but WITHOUT ANY WARRANTY; without even the implied warranty of      *
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the        *
 * GNU General Public License for more details.                        *
 *                                                                     *
 * You should have received a copy of the GNU General Public License   *
 * along with this program; if not, write to the Free Software         *
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,          *
 * MA 02110-1301, USA.                                                 *
 *                                                                     *
 * Contributors:                                                       *
 * - [Your Name]                                                       *
 **********************************************************************/

Package Structure

iDempiere follows a logical package structure:
  • org.compiere.model - Model classes (persistent objects)
  • org.compiere.process - Business processes
  • org.compiere.util - Utility classes
  • org.adempiere.webui - Web UI components
  • org.idempiere.test - Test cases

Naming Conventions

  • Use PascalCase for class names
  • Model classes start with M (e.g., MOrder, MInvoice)
  • Process classes end with Process (e.g., GenerateInvoiceProcess)
  • Test classes end with Test (e.g., SalesOrderTest)
  • Use camelCase for method names
  • Use descriptive names that indicate what the method does
  • Boolean methods should start with is, has, or can
  • Use camelCase for variable names
  • Constants should be in UPPER_CASE with underscores
  • Use meaningful names that describe the variable’s purpose
  • Use database column naming conventions
  • Prefix with table abbreviation (e.g., C_Order_ID, M_Product_ID)

Code Quality Guidelines

General Principles

Write Clean Code

  • Keep methods short and focused
  • Use meaningful variable and method names
  • Avoid deep nesting
  • Follow DRY (Don’t Repeat Yourself) principle

Document Your Code

  • Add Javadoc comments for public methods and classes
  • Explain complex algorithms
  • Document assumptions and limitations

Handle Errors Properly

  • Use appropriate exception handling
  • Log errors with meaningful messages
  • Don’t swallow exceptions silently

Optimize Performance

  • Minimize database queries
  • Use appropriate data structures
  • Cache when appropriate
  • Profile before optimizing

Database Best Practices

  • Use prepared statements to prevent SQL injection
  • Always close database connections properly
  • Use transactions appropriately
  • Minimize the number of database round trips
  • Use connection pooling

UI Development

  • Follow the existing UI patterns and conventions
  • Ensure accessibility
  • Test in different browsers
  • Support responsive design principles

Testing Requirements

See the Testing Guide for detailed information about writing and running tests.

Test Coverage

  • Write unit tests for new functionality
  • Ensure existing tests pass before submitting PR
  • Add integration tests for complex features
  • Test edge cases and error conditions

Test Data

  • Use Garden World data for testing when possible
  • Test on test sites before submitting
  • Ensure tests are repeatable and deterministic

Code Review Process

All code contributions go through a review process:
1

Automated Checks

Your pull request will be automatically checked for:
  • Build success
  • Test passage
  • Code style compliance
2

Peer Review

Core contributors will review your code for:
  • Code quality and standards compliance
  • Functionality and correctness
  • Performance implications
  • Security concerns
3

Address Feedback

Respond to review comments and make requested changes:
  • Push additional commits to your branch
  • Explain your approach if needed
  • Ask questions if feedback is unclear
4

Approval and Merge

Once approved, a maintainer will merge your contribution:
  • Your code becomes part of iDempiere
  • You’re listed as a contributor
  • Your changes will be in the next release

Plugin Development Standards

If you’re developing plugins, refer to:

Plugin Best Practices

  • Keep plugins focused on specific functionality
  • Document plugin configuration and usage
  • Provide installation instructions
  • Maintain compatibility with iDempiere versions
  • Follow the same coding standards as core
iDempiere is licensed under the GNU General Public License (GPL) version 2.
All contributions must be compatible with GPL v2. By contributing, you agree that your contributions will be licensed under the same license.

Getting Help

If you have questions about code standards:

Additional Resources

Contributing Guide

Learn the contribution workflow

Testing Guide

Learn about testing in iDempiere

Wiki

Browse comprehensive documentation

GitHub

View the source code