# ADempiere packs ERP, CRM, manufacturing and POS into one Java tree

> ADempiere is a GPL-2.0 Java business suite that covers ERP, CRM, manufacturing, supply chain and point of sale in a single repository built on several build systems at once. It suits implementors who want a configurable, community-driven alternative to a proprietary suite, and it is a large codebase with an uneven release history.

**adempiere/adempiere** — ADempiere Business Suite ERP/CRM/MFG/SCM/POS done the Bazaar way in an open and unabated fashion. Focus is on the Community that includes Subject Matter Specialists, Implementors and End-Users.

- Repository: https://github.com/adempiere/adempiere
- Website: http://www.adempiere.io
- Stars: 888 · Forks: 797
- Language: Java
- License: GPL-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/adempiere-adempiere

## One suite, five business domains

ADempiere is described as a Business Suite covering ERP, CRM, MFG, SCM and POS, and the repository name and layout confirm that it is one product rather than a family of separate applications.

The primary language is Java, and the scale is visible in the top-level entries. There are separate source trees for the core platform and for each business domain: org.adempiere.crm, org.adempiere.pos, org.adempiere.production, org.adempiere.project and org.adempiere.request for the ERP areas, org.adempiere.webservice for the web service layer, and org.adempiere.test for the test harness. Alongside the adempiere-branded trees there are the eevolution and spin packages, with org.spin.authentication, org.spin.finance_management, org.spin.hr_time_and_attendance, and org.eevolution.cashflow, distribution, freight, hr_and_payroll, manufacturing and warehouse.

Two of those names carry meaning for anyone evaluating it. the eevolution packages cover manufacturing, distribution, freight, HR and payroll and cash flow, and the spin packages cover finance management, HR time and attendance and authentication.

The positioning statement in the README is about process rather than technology: it is done the Bazaar way in an open and unabated fashion, with the focus on a community that includes Technical Specialists, Functional Specialists, Implementors and End-Users. That word, Bazaar, is doing a lot of work, and it describes the delivery model as much as the software. An implementation is not a configuration file you import, it is a process an implementor and the business together define.

## The repository still carries three build systems at once

The top-level listing tells you how old this codebase is, and it is not a criticism so much as a fact an adopter has to plan around.

There is a build.xml, an Ant build, a build.gradle for Gradle, a build.sbt for sbt, and an adempiere.iml module file alongside the .classpath and .project files that Eclipse uses. There is also a nbproject directory, which is NetBeans metadata, and an adempiere.psf project file. That is four generations of Java project tooling coexisting in one tree.

The GitHub Actions badges show which of them are actually in use. There is a main workflow and a build_with_gradle workflow, both on the develop branch, and a publish_with_gradle workflow and a release workflow, both on the 3.9.4 branch. So Gradle is the live build system, the older Ant and sbt files are still there for history or for other paths, and the release pipeline runs from a release branch rather than from develop.

That branching arrangement is the single most important operational fact in the repository. A build on develop is the current code, and a release is cut from a 3.9.4 branch, which means the published artefacts and the branch are different lines of work.

The rest of the tree explains the platform. There are GlassFish and JBoss facet directories, a launch directory, an install directory, and a data directory, alongside the interface, extension and extend directories, a migration directory, a looks directory for themes, JasperReports directories for reporting, and a Ground directory. The build_sbt, build.gradle and build.xml files are the visible entry points, but the platform layers are what you would actually read to understand how a deployment is put together.

## Where the source of truth is, and how to get the code

The README is a link board rather than a manual, and the links are the documentation.

The official page is adempiere.io, the official docs are at adempiere.io/docs, and the business process page is at adempiere.io/product/business-process.html. There is a source code page at adempiere.io/product/source-code.html whose anchor is about cloning the repository with a slow connection, which tells you that the repository is large enough for the clone to be a real consideration on a poor link.

That business process link is the one to read first. A suite like this is delivered as a configurable process model rather than a fixed application, so the question for a prospective implementor is not what features exist but whether the process the suite encodes resembles the way the business already works, and how far it has to be adapted. Reading that page before the code is the correct order.

For bugs, the README points at the GitHub issue tracker rather than at a support channel, which is consistent with a community project. There is a Discord badge and a Gitter badge for discussion, and the code of conduct, contribution route and community are described as the focus of the project.

The licensing surface is worth noting before anything is downloaded. The licence field on the repository says GPL-2.0, and the tree carries a LICENSE file plus license.html and license.txt at the top level. A GPL-2.0 business suite is fine for an organisation running it internally, and it is a different matter entirely for anyone distributing a modified version.

## A release history with a long gap in it

The version story needs reading carefully, because it is the part most likely to affect a decision.

The recent releases are 3.9.4.001 on 2023-12-20, described as a micro version, 3.9.4 on 2023-01-25, and 3.9.3 on 2019-12-02. So the newest tagged release is from the end of 2023, the one before it is from January 2023, and the one before that is from 2019.

Meanwhile the repository is not archived and the last push was on 2026-10-18, with the default branch being develop rather than main. So there has been a great deal of work on the branch since the last tag, and the published artefacts and the current code are not the same thing.

That gap is not a sign of abandonment. The badge set shows pull request and issue activity, a Discord for the community, and a release workflow that cuts tags from a 3.9.4 branch rather than from develop. It is a sign of a project whose release cadence has slowed and whose trunk has moved on.

For an adopter, that has a concrete consequence. If you deploy from a release, you deploy 2023 code. If you deploy from develop, you are running a moving target that nobody has signed off as a release. Both are legitimate choices, but they should be made deliberately, and the micro version numbering, 3.9.4.001, suggests the project uses a three-part scheme where the trailing part is a patch inside a minor, so you have to check which branch a given artefact actually came from.

The upgrade cost, in other words, is not a dependency bump. It is a decision about which line you are on and who tests it.

## A suite you configure rather than install

The characteristic trade-off of a suite like this is the one the business process page exists to explain, and it is worth stating plainly for anyone comparing it to a commercial ERP.

A commercial suite arrives with a defined behaviour and a defined upgrade path, and the cost is licence fees, a constraint on customisation, and a vendor roadmap. An open suite like ADempiere arrives as a set of building blocks and a community, and the cost is that the behaviour has to be assembled, usually with an implementor who understands the model.

The repository layout backs that reading. The extension and extend directories, the Ground directory, and the looks directory for themes are all places where a deployment is customised, and the presence of a migration directory suggests the process definitions themselves are versioned artefacts that a deployment carries forward. The CRM, POS, production and request trees are domains that share the same platform underneath, which is what allows a single deployment to run, for example, a manufacturing operation with a point of sale in the shop.

The reporting side is handled by JasperReports, with a JasperReports directory, a JasperReportsTools directory and a JasperReportsWebApp directory, which is the usual arrangement for an open suite that needs formatted documents without a commercial reporting licence.

What this means for a team evaluating it is that the comparison is not feature against feature with a commercial product. It is a comparison between a configuration project and a subscription. A small operation with a willing implementor may find the second option far more expensive. A company that has already paid a consultant to model its processes may find it the cheaper path, because the model is portable into a system it controls.

## Who this suits, and what to check before committing

Three things are worth verifying before anyone spends time on this, and none of them is the feature list.

The first is the process fit, and the business process page is where to check it. The suite encodes a way of doing things across purchasing, manufacturing, warehousing, distribution and retail. If your business already runs that way, the work is configuration. If it does not, the work is a process redesign with a suite as the tool, and the schedule should be written on that basis rather than on a deployment estimate.

The second is the branch you will actually run, and the answer is not in the README. A 3.9.4 micro release from December 2023 and a develop branch pushed in October 2026 are very different propositions for a system that holds your books. If you deploy the release, you want to know who is running it and where they get patches. If you deploy develop, you need your own test and upgrade discipline, because nobody else is doing that for you.

The third is the licence, and it deserves a sentence of its own. The licence field says GPL-2.0, and the tree carries the licence text. Running the suite internally to run your own business is a different use from redistributing a modified version, and the second one obliges you to publish the modified source. A system of this kind is often customised, and the point at which customisation is published is a question for your legal advisers rather than for this review.

The community framing in the README is the honest summary of the project. It is a suite maintained by and for implementors and end users, with a Discord and an issue tracker, and the work is visible on a branch that moves faster than its tags. For a business that wants to own its system, that trade can be a good one. For a business that wants a support contract, it is the wrong shape.

## Conclusion

ADempiere suits a small manufacturer, distributor or retail operation that wants ERP, CRM, manufacturing and point of sale in one configurable system and is prepared to work with a community-maintained codebase rather than a vendor with a support contract. It is the wrong tool for a company whose accounting or reporting requirements are strict and audited, because the configuration model means the behaviour is assembled per deployment and the release history is uneven, with the newest tagged release from 2023 while the branch has moved on. Before you adopt it, read the business process page linked from the project so you know what the process model expects of your business, confirm the release you would actually deploy, since the last tagged release is 3.9.4.001 from 2023-12-20, and remember that the project is GPL-2.0, so any derivative distribution carries that obligation.

## FAQ

### What does the ADempiere Business Suite cover?

It is described as an ERP, CRM, MFG, SCM and POS suite. The repository carries separate source trees for CRM, point of sale, production, project and request, alongside the eevolution ERP extensions and the spin accounting and banking foundation.

### What licence is ADempiere released under?

The licence field on the repository says GPL-2.0, and the tree carries a LICENSE file along with license.html and license.txt at the top level. Running the suite internally and redistributing a modified version are different uses under that licence.

### Which branch does ADempiere release from?

The default branch is develop, and the build badges show the main and build_with_gradle workflows running on develop while the publish_with_gradle and release workflows run on the 3.9.4 branch. The most recent tagged release is 3.9.4.001 from 2023-12-20.

### What build systems does the ADempiere repository carry?

The top level holds a build.xml for Ant, a build.gradle for Gradle, a build.sbt for sbt, and NetBeans and Eclipse project metadata. The GitHub Actions badges show Gradle as the build in active use, with the publish and release workflows running from the 3.9.4 branch.

## Sources

- [adempiere/adempiere on GitHub](https://github.com/adempiere/adempiere)
- [License: GPL-2.0](https://github.com/adempiere/adempiere/blob/develop/LICENSE)
- [Project website](http://www.adempiere.io)
- [README](https://github.com/adempiere/adempiere/blob/develop/README.md)
- [Releases](https://github.com/adempiere/adempiere/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/adempiere-adempiere