Branch GlobalQSS 361

From ADempiere ERP Wiki
Revision as of 04:50, 5 May 2011 by CarlosRuiz (talk | contribs) (fixing wrong links)
Jump to navigationJump to search

What is

Branch GlobalQSS Adempiere361 is an Adempiere subproject maintained by Carlos Ruiz, sponsored by GlobalQSS company.

Branch is totally open source, open for everybody to contribute, intended to establish proper governance and improve quality assurance procedures.


Six words can describe our vision on the project -> QUALITY SOFTWARE COMMON EXTENSIBLE PRODUCT CODEBASE

  • QUALITY SOFTWARE: Because we believe that a piece of software which is vital for enterprises must have basic rules that are respected by maintainers, rules so simple like code must be tested, and rules more complex like backward compatibility, clear migration path, etc.
  • COMMON: Because we consider silly to have forks per implementor (something usual in Compiere times), all implementors have some common requirements, there is a common kernel of needs that everybody requires, and our goal is to include common needs in a configurable way when the need can vary slightly in different scenarios.
  • EXTENSIBLE: Not everything needs to be included in the common kernel, there are non-common needs that require to be treated as an extension, and our vision is to evolve the project to a very extensible kernel
  • PRODUCT CODEBASE: Because we believe that Adempiere must be managed like a common product, not like a project. Product not in the "commercial" sense of the word, but in the management sense, when we have a vision to manage Adempiere as a product then backward compatibility becomes important, maintenance of installed base becomes important, and all the concepts that a Software House consider to have a quality product. Project vision tend to sacrifice those product things in the search for quick results. We prefer slow results with a proper quality.

What we want to achieve

  • A quality Adempiere product that can be useful for companies just after installed, no need to hire a company to fix the bugs, the downloaded software MUST run smoothly since the beginning

What we want to avoid

  • People committing incomplete or untested things pushing others to complete/review/fix their underdeveloped code
    • Please note this is not going against the principle Release early, release often, we want to encourage people to contribute, but, when you're conscious about the incompleteness of your code, or the lack of enough tests, then please share it in an experimental branch, and allow things to evolve with a proper peer review there. Experimental branches are by definition unstable, you must cope with the possibility of more frequent crashes or even data loss. In this branch the goal is to provide a safer environment for people using this software in production, with specific needs of stability and a safer evolution path.
  • Companies maintaining their own private version without sharing even the most basic bugs
  • Companies/people exploiting instability to sell stabilization services (like in Compiere times)

What is included

The subproject is composed by the folders:


Write-permissions over the three folders composing the branch are exclusive to branch maintainers, no one else must commit directly on the branch, but anybody can contribute sending patches for peer review and indeed we encourage community to send us patches (in a proper format) to improve the product.

The People


The right to add/drop maintainers is reserved to the main maintainer:

At this stage there are no more maintainers defined for the project, and the idea is to keep the number low, we expect most of contributions to arrive via patches instead of direct commits.

There is provision for module maintainers, this is maintainers of a specific functionality, extension, module. These maintainers will have permissions to do direct commit on things related to their scope.


The subproject has a functional/technical team to review, discuss and vote for functional specifications, technical discussions and architectural movements.

The team is composed of:

How to contribute

There are plenty of ways to contribute, reporting bugs, bringing ideas, suggesting functional specifications,

Reporting bugs

To report bugs please follow the guide How to report a bug

Bringing ideas

To report an idea please use the legendary Red1 forums

Suggesting functional specifications

To suggest a functional specification please follow the Functional Specification Process

Contributing code for functional specifications

If you have code to contribute, please follow first the Functional Specification Process.

If you want to contribute the code for an already approved Functional Specification, then please open a contribution tracker and upload there your patches, 2pack and migration scripts.

Contributing sponsorship for approved functional specifications or technical/architectural improvements

If you want to contribute with money to develop any approved functional specification or technical/architectural improvement, please contact Carlos Ruiz writing an e-mail to [1]


Patches policies

Code must be contributed via patches, patches must be complete, include migration scripts for oracle and postgresql databases, or include a 2pack with all the modifications required to dictionary.

If the code is to fix a bug, the bug report must follow the How to report a bug format.

If the code is to implement a functional specification, then FS must follow the Functional Specification Process, and there must be a document explaining the implementation following the format Functional Specification Template

Try to send your patches generated using the latest version of code, maintainers reserve the right to reject to review a patch that doesn't follow the guidelines expressed here.

Contribution policies

There are guidelines to follow when contributing.

  • First of all, please read and try to apply the ADempiere Best Practices, many of them are suggestions, but is highly encouraged to follow most of them
  • please read and follow the Release Commit Rules, all of them are mandatory

There are other important behavioral guidelines that you must follow:

  • When integrating patch from others, please ALWAYS give credit to the original writer of the code. It can be adding comments in the code expressing who wrote it (not recommended), but is compelling to include a comment in the commit giving the credit to the author
  • Please take note that you're responsible by the code you integrate, if you take code from other people to integrate, you become responsible for the quality of that code, INTEGRATION IS NOT A COPY/PASTE JOB, integration is peer review and quality assurance job. An answer like "I don't know, I just integrated" is not valid when requesting explanation or fix about the contributed code.
  • You are responsible for the things you commit, when requested for an improvement or a fix an answer like "Feel free to fix it" is not valid (of course you can answer like that, we cannot stop you, but you're damaging the trust we can put on you).

Design guidelines

There are design guidelines to follow when contributing:

  • You must always assume that final user is not aware about what he's doing.
    • For example, deleting in cascade must be considered carefully, implementing delete in cascade can allow a distracted user to inadvertently delete things they don't want to delete. It's always preferrable to compel the user to confirm all the potentially dangerous things before changing data. In general terms, cascade delete (automatic deletion of child records) must be done just for automatically created records (like translation, accounting, tree)

Where to download

Mercurial repository

HTTPS access

Setting a local clone

To make modifications to this branch the recommended way is to create a local clone of the repository, this can be achieved executing:

If you plan to make changes to libero or liberohr you can clone also the corresponding folders.

After you clone the remote sourceforge server, you can clone locally, i.e:

  • hg clone adempiere361 mylocalclone

Then please feel free to make changes in your local copy (mylocalclone in the example) and test them.

Committing your changes

Commit in mercurial is different to commit in subversion. Executing "hg commit" just apply the changes to your local clone.

Please choose a proper commit message that summarizes properly the change, and please fill the user information with your sourceforge user, or your e-mail.

Sending your changes for peer review

After you test your changes, let me repeat, after you test your changes and you consider they are complete and ready for production you can share your changes for peer review.

  • NOTE: You could agree in an experimental way to share incomplete changes, that is ok for example within a team working on a feature, or agreeing to cross-test, but that is not ok to send your changes for consideration to production.

There are several ways to send your changes for peer review (reference

Create a patch (recommended)

You can create a patch of the committed changes and send the patch to committers via e-mail, or upload to a sourceforge tracker.

  • "hg outgoing" let you review the unsent changes and take note of the revision
  • "hg export <revision>" > patch.diff" creates a patch.diff file with the changes from revision

You can fork on sourceforge (recommended if you know how to play with mercurial)

You can fork adempiere361 (or the other folders) within sourceforge (please coordinate with maintainers to check how to achieve this on sourceforge)

Publish in a public repository so I can pull changes from your repository

You can create a clone (fork) in a repository different than sourceforge (for example bitbucket), and then let maintainers know the revision to check and pull to get the corresponding changes.

Send a bundle

This is similar to create a patch, but a bundle can even contain a whole repository - check hg documentation about bundles

Subversion repository

No longer maintained

Patches strategy for 360

You can download version 360 and patches from:

How to set up eclipse


Although the project can be compiled and modified using other IDEs (like netbeans) it's recommended to use eclipse.

Please download and install the corresponding version for your operating system and processor from the URL:

It's recommended to download the version named "Eclipse IDE for Java EE Developers" in case you want to debug directly the zkwebui server. "Eclipse IDE for Java Developers" could be enough for people using just swing or planning remote debug.

Mercurial for Eclipse

It is recommended to install the mercurial client for eclipse available here:

Easier way to install is within eclipse:

  • Help -> Install New Software ->
  • fill "Work with:" ->
  • push the Add button and give a proper name to save the site
  • Enable the checkbox to install "Mercurial Eclipse" and push Next and then follow normal eclipse instructions to install software

Is it possible that you need to install mercurial (hg) for your operating system also.

  • i.e. in ubuntu is just a matter of "sudo apt-get install mercurial"

Set up project


How to build


How to install from scratch


How to install as patches for 360



Reference Manual




Entity-Relationship Schema and Database Description


Features Been Done