Branch GlobalQSS 361

From ADempiere ERP Wiki
Revision as of 21:36, 4 February 2012 by CarlosRuiz (talk | contribs) (upgrading this page to reflect latest news and repository)
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.

Transition Version to iDempiere

IMPORTANT NOTICE: This branch has been defined as the transition branch to the iDempiere=OSGi+ADempiere project, guaranteeing the most possible smooth transition (DB upgrade will be as always just applying migration scripts). All the bugs (more than 200) and new functionalities fixed on this branch are already included (and constantly added also) into iDempiere.


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 folder:


Write-permissions over 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 other maintainers is reserved to the main maintainer:


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.

The official site to report bugs or suggest new features for this branch or iDempiere is

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 an iDempiere JIRA ticket 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:

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

  • hg clone adempiere361 mylocalclone
  • hg update globalqss_adempiere361

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 within bitbucket very easily, just follow the fork link or follow this link.

After forked in bitbucket you can then use the "pull request" mechanism to contribute back.

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

You can create a clone (fork) in a repository different than 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

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"

Features and Bug Fixes Done

  • Too many to document here - you must follow the history of the project to find them.