Commonsプロジェクトは、Jakartaに新規参入した開発者から、相当数の提案・パッチを受けています。提案・パッチを行うための支えとなる多くの情報がJakartaプロジェクトウェブ内に確かに存在して入るものの、中々発見しづらいのが現状です。この文書は、パッチに関する情報を一つのわかりやすいリファレンスとして集めたものです。

この文書を読み進む前に、Jakarta投稿ガイドを一瞥する時間を多少なり取ってください。

オリジナルファイルのスタイルをどうぞ尊重してください。そのオリジナルのスタイルと自分が追加するものがフィットしているかどうか、確認してください。

全てのコンポーネントには、コーディング基準が存在し、全ての投稿はその基準に沿うよう求められています。あるコンポーネントで使われる基準を見つけるのは多少困難なことでしょうが、オリジナルのスタイルに拘れば、それで十分だと思われます。

もし、投稿されたパッチがコンポーネントのコーディング基準を満たすものではなかったとすれば、コミッタがそのパッチを書き換えなければならないか、あるいはパッチ自体拒否されるでしょう。この始めの段階で正しく行うことで、書き換えをする手間を省くことが出来るようになるのです。

Spaces Not Tabs

PLEASE NO TABS! The source should be indented using spaces rather than tabs. The standard indentation is 4 spaces per indent - but respect the number of spaces used by the original. Some IDEs include automatic source (re)formatting. If you use an IDE, please check that this feature is either disabled or set to use (4) spaces. If a patch is submitted which uses tabs rather than spaces, then either a committer will have to reformat it before it's applied or the patch will be rejected. Again, it's easier to get it right in the first place rather than have to reformat and resubmit your patch.

Components in the commons use JUnit for unit testing. If you're not familiar with the principles of regression testing, then the JUnit site has some good articles.

Before you submit your patch, please do a clean build of the full distribution and run the unit tests (this can be done from the build script). This ensures that your patch doesn't break any existing functionality.

We strongly recommend that you create and submit test cases together with the rest of your contribution. Test cases ensure that bugs stay fixed and features don't get broken. Test cases will probably be needed anyway so submitting them saves time.

CVS HEAD is the current source. It's stored in cvs. If you're not familiar with cvs, then consult these references

Please create your patch against CVS HEAD since this makes the job of applying the patch much easier. If you don't have a version checked out of cvs, then check one out. If you have, then please do a fresh update before you make your changes.

The patch should be in unified format. You can create a patch in this format (from cvs) by using:

      cvs diff -u File >> patchfile
  

Try to give your patch files meaningful names. This makes it easier for developers who need to apply a number of different patches.

補足（訳注：訳者が書いた部分です）：

もしWinCVSをお使いでしたら、メニューの[Admin]から[Command Line]に進み、（[Commandline Settings] タブがアクティブであることを確認し）[Enter a cvs line command]の入力項目にてcvs diff -uと打ってみてください。勿論、其の前に、ターゲットとするディレクトリあるいはファイルを指定しておく必要があります。そうする事で、（Apache Jakarta プロジェクトで一般的に使われる）"unified diff"形式のdiffを生成することが出来ます。（訳注：あとは、コピー＆ペーストでファイルに保存すると良いでしょう）

言い換えれば、[Alt+A]+[Alt+C]+[Alt+C]のあとに"cvs diff -u"を入力する、です。

There are two ways to submit a patch:

• バグレポートに添付としてパッチを追加する方法。
• 適切なdevメーリングリストに添付としてパッチをメールする方法。メールのサブジェクトには、プレフィックスとして[PATCH]を追加し、そのパッチがどのようなものであるかを記述して措いてください。どのコンポーネントの為のパッチであるかを明確にして措いてください。わかりやすくするため、サブジェクトの[PATCH]のあとに、コンポーネント名を入れておくと良いでしょう。

でも..どっちが本当は良いんでしょう？ どちらの方法であっても、同様に受け入れられます！

If it's a big patch then adding it to a bug report will save bandwidth on the mailing list (but remember to include the url in any follow-up discussions). Using a bug report also allows you to be automatically posted with status updates. Posting to the mailing list takes you closer to the action.

If the patch is a fix for a bug that's already been reported then it's best to add it as an attachment to the bug report. This not only makes management easier but also it stops other developers out there wasting their time by developing independent fixes!

In either case, please give a detailed description of what your patch does and some reasons why it should be committed (if it's not obvious).

All the commons documentation is in cvs - including this document. If you see anything that's wrong or you think that you can add something that's missing then please submit a patch!

TIA