IDempiereコードへの貢献

　このコンテンツは、Diego Ruizと Thomas Bayen BXService GmbH所属により提供されています。 もし質問や改善の提案があったら、気軽にan emailまでメールして下さい。

このコンテンツは IDempiereコミュニティーへの貢献の一部です。

このチュートリアルの目的

このwikiの目的は、iDempiereのソースコード(Trunk)へのコミット(プッシュ)する事を目標とした改善等の開発方法を示すことです。 人々が心の中で考えてコード化した素晴らしい改良や貢献がたくさんあります。しかし、いくつかの詳細が不足しているために、それらはコミットされません。

共通の課題

iDempiereは偉大なオープンソースプロジェクトであるため、高い品質基準を持つ必要があります。 コードをコアにプッシュすることは、新しい開発を行う際にカバーしなければならないいくつかの意味合いを持っています。そのうちのいくつかを紹介します。:

• PostgreSQL と Oracleの両方で動作しなければなりません。
• 新しい機能は以前の機能を壊すことはできません。(これは当たり前のように聞こえますが、十分なテストをしないとこの間違いを犯しやすいです)
• 下位互換性を確認しましょう。未使用のフィールドが見つかった場合は、多くの実装で人によって異なる方法で使用できると仮定してください。
• コメント、メソッド、変数は英語でなければなりません。
• 常にコミュニティでソースコードをレビューする人の事を考えてください - 理解しにくいコードはコメントした方が良いですが、コメントの必要性が過剰になると、名前やアルゴリズムが改善される可能性があります。
• 大きなことや大きな変更には、大きなドキュメント（マニュアル、ユースケース、テストケース）が必要です。
• 新機能のコードとリファクタリングのコードを混ぜるとレビューが大変です。どちらの場合も異なるコミットをお願いします。
• 可能な限りSQLコードを避け、代わりにモデルクラスを使用して下さい。

人々がコミュニティーの事を気にせずに自分のニーズを満たすことだけを考えてしまうと、コードが通用しなくなり、進化させることはある時点で難しくなるか、不可能になってしまいます。

そこで、私たちはこのチェックリストを作成して、誰もがより簡単に優れたコードを投稿し、このコミュニティの一員となり、継続的な支援と貢献で知られるようにすることを決めました。

How to Contribute

This is a checklist of the main/minimum things that should be done to contribute in the core:

• If you need to change the database check the Changing the database chapter first.

Note: If your development needs the database changes and you don't do this first. You will have to do it all over again

• Every commit must be related to a Jira ticket. Please do not mix commits, if the new code needed a refactoring of old code, create one patch for refactoring and one for the actual solution (This makes it easier for review).
• When you want to get data. The best way to do it is in the following order:
  • Model Classes. Most of the M classes in iDempiere have a get method to avoid reading from the database.
  • Query Class.
  • DB Class (DB.get())
  • And finally JDBC, only if it is really needed as the impact in the memory is greater than the approaches above.
• Java classes, methods and variable formats. Follow the java standards (meaningful names, camel case). The code should be indented to improve its readability and maintainability.
• Make sure each java class has the GPLv2 Header.
• I think the most important one is the collateral analysis of your code. Even if you changed one line that you think doesn't have a huge impact. Make sure to know where this change affects the behavior in other classes, where is it referenced, and test the corresponding cases to check that you're not injecting new bugs with your contribution.
• Make sure you don't fall in one of the Common Issues

When you have finished the previous steps create the patch with a commit message including the ticket number in JIRA so it updates automatically between the repository and the jira ticket.

Changing the database

• If the database was changed and official IDs are needed:
  • First you need to Manage the Centralized IDs
  • Then Generate the Migration Scripts
  • When generating a migration script is a good practice to set the right value for the DICTIONARY_ID_COMMENTS SysConfig key. The migration script will take it, while also helping other developers to know what is being worked on when they receive the email of an official ID assignment.
• When you have successfully created your migration scripts name them with this format: yyyymmddhhmm_ticket.sql
• Add at the end of both migration scripts the register line e.g: SELECT register_migration_script('201504180139_IDEMPIERE-2556.sql') FROM dual
• Copy the respective scripts into the PostgreSQL folder and the oracle folder (migration/i2.1z/...)

Changing the code

• When adding, removing or changing the signature of a public method. It's advised to regenerate the serialVersionUID.
• When changing the signature of a public method, better do an overload.

it helps others customize code or plugin can working.