Apache Ant Task Design Guidelines

Apache Ant タスク設計ガイドライン

This document covers how to write ant tasks to a standard required to be incorporated into the Ant distribution. You may find it useful when writing tasks for personal use as the issues it addresses are still there in such a case.

このドキュメントでは、Ant のディストリビューションに入れるのに必要な基準に従ったAnt タスクの作成法について述べています。 このドキュメントが取り組んでいる問題が今なおあるので、 このドキュメントは個人利用のためにタスクを作成する際に役立つでしょう。

Don't break existing builds

既存のビルドを壊さない

Even if you find some really hideous problem with ant, one that is easy to fix, if your fix breaks an existing build file then we have problems. Making sure that every build file out there still works, is one of the goals of all changes. As an example of this, Ant1.5 passes the single dollar sign "$" through in strings; Ant1.4 and before would strip it. To get this fix in we first had to write the test suite to expose current behaviour, then change something so that singe $ was passed through, but double "$$" got mapped to "$" for backwards compatibility.

Ant において本当に恐ろしい問題を発見し、それが簡単に修正できるものであったとしても、 あなたの修正が既存のビルドファイルを動作させなくするならば、 我々は困ったことになります。 今ある全てのビルドファイルが動作することを確認することは、 全ての変更の目的の一つです。 このような例として、 Ant 1.5 では、文字列中の一つのドル記号 "$" を読み飛ばします。 Ant 1.4 以前では、それを削除します。 これを修正するために、 まず最初に現在の振舞いを明らかにするために、 テストセットを書かなければなりませんでした。 そして、下位互換性のために一つの $ は読み飛ばし、 二つの "$$" は "$" にマップするように変更しました。

Use built in helper classes

組み込みのヘルパークラスの利用

Ant includes helper tasks to simplify mauch of your work. Be warned that these helper classes will look very different in ant2.0 from these 1.x versions. However it is still better to use them than roll your own, for development, maintenance and code size reasons.

Ant には、 作業の多くを簡単にするためのヘルパータスクがあります。 これらのヘルパークラスは Ant 1.x 版と Ant 2.0 版のとではとても違いがあるように見えるという注意があります。 しかしながら、開発、保守、およびコードサイズの理由から、 自分で書くよりもそれらを使ったほうが良いでしょう。

Execute

(外部プログラムの)実行

Execute will spawn off separate programs under all the platforms which ant supports, dealing with Java version issues as well as platform issues. Always use this task to invoke other programs.

(外部プログラムの)実行では、 Java のバージョンおよびプラットフォームの問題を扱いながら、 Ant がサポートする全てのプラットフォーム上で別のプログラムを生成します。 他のプログラムを起動するためには、常にこのタスクを使います。

Java, ExecuteJava

Java および Java の実行

These classes can be used to spawn Java programs in a separate VM (they use execute) or in the same VM -with or without a different classloader.W hen deriving tasks from this, it often benefits users to permit the classpath to be specified, and for forking to be an optional attribute.

これらのクラスは、(実行するのに使う)別の VM 、あるいは、 同じ VM で、 異なるクラスローダーを使ったり、使わなかったりして、 Java プログラムを起動するのに使います。 これからタスクが派生する際に、 ユーザが指定されるクラスパスを許可したり、 オプションの属性であるように起動するために利点があります。

Project and related classes

プロジェクトおよび関連するクラス

Project, FileUtils, JavaEnvUtils all have helper functions to do things like touch a file, to copy a file and the like. Use these instead of trying to code them yourself -or trying to use tasks which may be less stable and fiddlier to use.

Project、FileUtils、JavaEnvUtils は全て ファイルにタッチしたりするようなことを行うためにヘルパー関数を持っています。 自分でコーディングしようとしたり、 あまり安定せず、ごまかされたタスクを使おうとせずに、 これらを使ってください。

Obey the Sun/Java style guidelines

Sun/Java スタイルガイドラインに従う

The Ant codebase aims to have a single unified coding standard, and that standard is the Sun Java coding guidelines

Ant のコードベースは、 一つの統合されたコーディング標準があり、 その標準が Sun Java コーディングガイドライン であることを目的としています。

It's not that they are better than any alternatives, but they are a standard and they are what is consistently used in the rest of the tasks. Code will not be incorporated into the database until it complies with these.

他の全ての選択肢よりもそれが良いとはいえませんが、 それは標準であり、それが、他の残りのタスクで一貫的に使われているのです。 これらを満足するまで、コードはデータベースに組み込まれません。

If you are writing a task for your personal or organisational use, you are free to use whatever style you like. But using the Sun Java style will help you to become comfortable with the rest of the Ant source, which may be important.

もし、あなたが、個人や組織で利用するためにタスクを書いている場合、 何でも自分の好きな方法を使って構いません。 しかし、Sun Java のスタイルに従えば、 Ant のソースの残りにおいて、あなたを快適にする手助けになるでしょう。 それが、重要なことなのです。

One important rule is 'no tabs'. Use four spaces instead. Not two, not eight, four. Even if your editor is configured to have a tab of four spaces, lots of others aren't -spaces have more consistency across editors and platforms. Some IDEs (JEdit) can highlight tabs, to stop you accidentally inserting them

一つの重要な規則は 'タブを使わない' という事です。 代わりに 4 つの空白文字を使ってください。 2 つでも、8 つでもなく 4 つです。 たとえ、自分のエディタが4文字分のタブに設定されていてもです。

Attributes and elements

属性および要素

Use the Ant introspection based mapping of attributes into Java datatypes, rather than implementing all your attributes as setFoo(String) and doing the mapping to Int, bool or file yourself. This saves work on your part, lets Java callers use you in a typesafe manner, and will let the Xdocs documentation generator work out what the parameters are.

全ての属性を setFoo(String) のように実装したり、 自分で整数、ブール値、ファイルなどにマッピングせずに、 Ant のイントロスペクションに基づく属性の Java データ型へのマッピングを使います。 これにより、自分の作業量を減らすことができ、 Java の呼び出し側に対し、安全なデータ型の方法で使わせるようにし、 Xdocs ドキュメント生成において、パラメータが何であるかわかるようになります。

The ant1.x tasks are very inconsistent regarding naming of attributes -some tasks use source, others src. Here is a list of preferred attribute names.

Ant 1.x タスクは、 属性名において、あまり一貫性がありません。- 一部のタスクはsourceを使い、また一部は srcを使っています。 次に推奨される属性名の一覧を示します。

failonerror boolean to control whether failure to execute should throw a BuildException or just print an error. Parameter validation failures should always throw an error, regardless of this flag / 実行が失敗したらBuildException例外を発生しなければならないか、 それとも単にエラーを表示すればよいか制御するブール値。 パラメータ確認の失敗は、このフラグにかかわらず常にエラーをスローします。
destdir destination directory for output / 出力先ディレクトリ
destfile destination file for output / 出力先ファイル
srcdir source directory / ソースディレクトリ
srcfile source file / ソースファイル

Yes, this is a very short list. Try and be vaguely consistent with the core tasks, at the very least.

もちろん、これは大変短いリストです。 少なくとも、コアタスクと一貫性があるよう心がけて、そして、 大体一貫性があるようにしてください。

Support classpaths

クラスパスの対応

Try and make it possible for people to supply a classpath to your task, if you need external libraries, rather than make them add everything to the ANT_HOME\lib directory. This lets people keep the external libraries in their ant-based project, rather than force all users to make changes to their ant system configuration.

外部ライブラリが必要な場合、 ANT_HOME\lib ディレクトリに全てを加えさせるより、むしろ、 あなたのタスクに対し利用者がクラスパスを指定できるよう心がけ、 そうなるようにしてください。 これにより、全てのユーザに Ant のシステム設定を変更させずに、 自分の Ant ベースのプロジェクト中に外部ライブラリを置くことができるようになります。

Design for controlled re-use

制御された再利用のための設計

Keep member variables private. If read access by subclasses is required. add accessor methods rather than change the accessiblity of the member. This enables subclasses to access the contents, yet still be decoupled from the actual implementation.

メンバ変数をプライベートにしておきます。 サブクラスによる読み取りアクセスが必要な場合は、 メンバのアクセス設定を変更せずに、アクセッサーメソッドを追加してください。 これにより実際の実装から切り離したまま、 サブクラスが内容にアクセスできるようになります。

The other common re-use mechanism in ant is for one task to create and configure another. This is fairly simple.

Ant における他の共通の再利用の機構は、 一つのタスクに対して、作成し、他を設定するということです。

Do your own Dependency Checking

タスク内での依存関係チェックの実行

Make has the edge over Ant in its integrated dependency checking: the command line apps make invokes dont need to do their own work. Ant tasks do have to do their own dependency work, but if this can be done then it can be done well. A good dependency aware task can work out the dependencies without explicit dependency information in the build file, and be smart enough to work out the real dependencies, perhaps through a bit of file parsing. The depends task is the best example of this. Some of the zip/jar tasks are pretty good too, as they can update the archive when needed. Most tasks just compare source and destination timestamps and work from there. Tasks which don't do any dependency checking do not help users as much as they can, because their needless work can trickle through the entire build, test and deploy process.

make には、 統合された依存関係チェックにおいて Ant よりも利点があります: コマンドラインアプリケーションである make の起動は、 自分自身の作業ではありません。 Ant タスクは自分自身で依存関係チェックを行わなければなりません。 しかし、これができたら、うまくいくのです。 優れた依存関係認識タスクは、 ビルドファイル中の明示的な依存関係情報がなくても、 依存関係を解釈することができ、 ちょっとのファイルのパージングにより、 実際の依存関係を調べるのに十分なほど洗練されたものです。 The depends タスクはこれに対する最高の例です。 一部の zip/jar タスクも、 必要な場合にアーカイブを更新dけいるので、かなり良い(例)です。 ほとんどのタスクは、 単にソースおよび出力先のタイムスタンプを比較し、 そこから作業します。 いかなる依存関係チェックも行わないタスクは、 ユーザのためにはなりません。 何故なら、その必要としない作業は、 全体のビルド、テスト、および配備手順から少しずつ漏れることがあるからです。

Support Java 1.1 through Java 1.4

Java 1.1 から 1.4 をサポートする

Ant is designed to support Java1.1: to build on it, to run on it. Sometimes functionality of tasks have to degrade in that environment -<touch> is a case in point- this is usually due to library limitations; such behaviour change must always be noted in the documentation.

Ant は、その上でビルドし、動作するために、 Java 1.1 をサポートするよう設計されています: 時として、ある状況によりタスクの機能を縮小しなければならないことがあります。 - <touch> は、そのような状況でした。 - これは通常、ライブラリの制限によるものです; そのような振る舞いの変更は、常にドキュメントに記されていなければなりません。

What is problematic is code which is dependent on Java1.2 features -Collections, Reader and Writer classes, extra methods in older classes. These can not be used directly by any code and still be able to compile and run on a Java 1.1 system. So please stick to the older collection classes, and the older IO classes. If a new method in an existing class is to be used, it must be used via reflection and the NoSuchMethodException handled somehow.

問題のとなるのは、Java 1.2 の機能である Collection、Reader、Writer クラスや、 古いクラスの追加メソッドに依存したコードです。 これらは、いかなるコードによっても直接使ってはなりませんし、 Java 1.1 システムでもコンパイルでき実行できなければなりません。 ですから、古い collection クラス、および、 古い IO クラスに固執するようにしてください。 既存のクラス中の新しいメソッドが使われたら、 リフレクションによって使われなければならず、 どうにかしてNoSuchMethodExceptionを扱わなければなりません。

What if code simply does not work on Java1.1? It can happen. It will probably be OK to have the task as an optional task, with compilation restricted to Java1.2 or later through build.xml modifications. Better still, use reflection to link to the classes at run time.

コードが単に Java 1.1 で動作しない場合はどうなるでしょうか。 これは、起こり得ることです。 build.xml の変更により、コンパイルを Java 1.2 以降に制限することにより、 そのタスクをオプションタスクとして持てば大丈夫でしょう。 それでもなお、 実行時にクラスへのリンクのためにリフレクションを使った方が良いでしょう。

Java 1.4 adds a new optional change to the language itself, the assert keyword, which is only enabled if the compiler is told to compile 1.4 version source. Clearly with the 1.1 compatibility requirement, Ant tasks can not use this keyword. They also need to move away from using the JUnit assert() method and call assertTrue() instead.

Java 1.4 では、言語自体への新しいオプションの変更、 assert という予約語が加えられました。 これは、コンパイラが、1.4 版のソースをコンパイルすると指定された場合のみ、 有効になります。 明らかに、1.1 との互換性の要求から、 Ant では、この予約語を使ってはなりません。 その代わりに、 JUnit の assert() メソッドを使い、 assertTrue() を呼び出すように変更しなければなりません。

Refactor

リファクタリング

If the changes made to a task are making it too unwieldy, split it up into a cleaner design, refactor the code and submit not just feature creep but cleaner tasks. A common design pattern which tends to occur in the ant process is the adoption of the adapter pattern, in which a base class (say Javac or Rmi) starts off simple, then gets convoluted with support for multiple back ends -javac, jikes, jvc. A refactoring to split the programmable front end from the classes which provide the back end cleans up the design and makes it much easier to add new back ends. But to carry this off one needs to keep the interface and behaviour of the front end identical, and to be sure that no subclasses have been accessing data members directly -because these data members may not exist in the refactored design. Which is why having private data members is so important.

タスクに対して行われた変更が扱いにくいものになってしまった場合、 設計が整然とするように分割し、 コードをリファクタリングし、 安定しているだけでなく、整然としたタスクを投稿しなければなりません。 Ant プロセスで起きる傾向にある共通のデザインパターンは、 アダプターパターンの適用です。 そこでは、ベースクラス(例えばJavac や Rmi)は最初は簡潔に始まりました。 複数のバックエンド javac、jikes、jvc のサポートにより、 難解なものになってしまいました。 設定可能なフロントエンドをバックエンドを提供するクラスから分離するリファクタリングにより、設計が整理され、新しいバックエンドを加えるのが、 より簡単になりました。 しかしながら、これをやり遂げるには、 フロントエンドのインタフェースおよび振る舞い一意な物にしておくこと、 そして、 データメンバーを直接参照するサブクラスが無いことを確認することが必要です。 なぜなら、これらのデータメンバーは、リファクタリングされた設計では、 存在しないかもしれません。 それが、プライベートデータメンバーを持つことが重要なのかという、 理由なのです。

Test

テスト

Look in jakarta-ant/src/testcases and you will find JUnit tests for the shipping ant tasks, to see how it is done and what is expected of a new task. Most of them are rudimentary, and no doubt you could do better for your task -feel free to do so!

jakarta-ant/src/testcases を見て、 Ant のタスクを配布できるよう、 そのタスクがどのように行われ、 新しいタスクに期待される事は何なのか理解するために、 JUnit テストがあるのがわかるでしょう。 それらの多くは基本的であり、 自分のタスクに対し良くできるか疑いはありません。 気楽にやってみてください。

A well written set of test cases will break the Ant task while it is in development, until the code is actually complete. And every bug which surfaces later should have a test case added to demonstrate the problem, and to fix it.

テストケースの良く書かれた集合は、 コードが実際に完成するまで、 開発中には Ant タスクを壊すことがあります。 そして、後に直面する全てのバグは、 その問題を実証するために、テストケースに加えられます。

The test cases are a great way of testing your task during development. A simple call to 'build run-test' in the ant source tree will run all ant tests, to verify that your changes don't break anything. To test a single task, use the one shot ant run-single-test -Dtestcase=${testname} where ${testname} is the name of your test class.

テストケースは、 コミッターが変更やパッチが意図した通りに動作しているか、 検証するのにも使われます。 テストケースがあれば、かなりの信頼性を高めることができます。 正確にするために、テストケースのない投稿を望んでいません。 何故なら、我々が自分で書かなければならないからです。 我々が必要とするか、多くのユーザにとって全く本質的であるとわかった場合のみ、 テストケースを作ります。

Remember also that Ant 1.x is designed to compile and run on Java1.1, so you should test on Java 1.1 as well as any later version which you use. You can download an old SDK from Sun for this purpose.

また、Ant 1.1 は Java 1.1 上でコンパイルされ実行されるように設計されていることを忘れないでください。 従って、使用する全ての最新版と同様に Java 1.1 でもテストしなければなりません。 この目的のために Sun から古い SDK をダウンロードすることができます。

Finally, run a full build test before and after you start developing your project, to make sure you havent broken anything else by accident.

最後に、 不注意で何かを壊していないか確認するために、 自分のプロジェクトを開始する前と後に、 全体の build test を実行します。

Document

ドキュメント

Without documentation, the task can't be used. So remember to provide a succint and clear html (soon, xml) page describing the task in a similar style to that of existing tasks. It should include a list of attributes and elements, and at least one working example of the task. Many users cut and paste the examples into their build files as a starting point, so make the examples practical and test them too.

ドキュメントが無ければ、 タスクは使えません。 そのタスクについて既存のタスクと同様のスタイルで記述した、 簡潔で明瞭な HTML (近々 XML になります) ページを提供するのを忘れないでください。 それには属性と要素の一覧、および、 少なくとも一つのタスクの動作例が含まれていなければなりません。 多くのユーザは、手始めに、 この例を自分のビルドファイルにカットペーストします。 従って、その例は実践的なもので、テストされたものにしてください。

You can use the xdocs stuff in proposal/xdocs to autogenerate your documentation page from the javadocs of the source; this makes life easier and will make the transition to a full xdoclet generated documentation build process trivial.

提案されているように、xdocs に類するものが使えます/ xdocs とはソースコードの javadocs からドキュメントページを自動生成するためのものです。 これにより、普段の作業が簡単になり、 xdoclet が生成する完全なビルドプロセスのドキュメントへの変換は、 取るに足らない事となります。

Licensing and Copyright

使用許諾と著作権

Any code submitted to the Apache project must be compatible with the Apache Software License, and the act of submission must be viewed as an implicit transfer of ownership of the submitted code to the Apache Software Foundation.

Apache プロジェクトに投稿される全てのコードは、 Apache Software License と互換性がなければなりません。 そして、投稿した事により、暗黙的に、 投稿されたコードの所有権は Apache Software Foundation へと、 移管されたものと見なされます。

This is important.

これは重要な事です。

The fairly laissez-faire license of Apache is not compabitible with either the GPL or the Lesser GPL of the Free Software Foundation -the Gnu project. These licenses have stricter terms, "copyleft", which are not in the Apache Software Foundation license. This permits people and organisations to build commercial and closed source applications atop the Apache libraries and source -but not use the Apache, Ant or Jakarta Project names without permission.

Apache の障害の無い自由放任主義なライセンスは、 Free Software Foundation(GNUプロジェクト) の GPL や Lesser GPL と互換性がありません。 これらのライセンスには厳密な用語 "copyleft(著作権の放棄)" が含まれています。これは Apache Software Foundation のライセンスにはありません。 これにより、 Apache、Ant や Jakarta Project という名前を使わずに、 Apache ライブラリやソースを用いて、許可なしで、 個人や組織が商用や組織内でのソースアプリケーションを構築できるようになります。

Because the Gnu GPL license immediately extends to cover any larger application (or library, in the case of GLPL) into which it is incorporated, the Ant team can not incorporate any task based upon GPL or LGPL source into the Ant codebase. You are free to submit it, but it will be politely and firmly rejected.

GNU GPL ライセンスは、すぐに全ての大きなアプリケーション( GLPL の場合はライブラリ)に対応するように組み込まれるものに拡張するので、 Ant チームは GPL や LGPL のソース基づくいかなるタスクも Ant のコードベースに組み入れることはできません。 投稿するのは自由ですが、 礼儀正しくも断固として却下されます。

Once ant-2 adds better dynamic task incorporation, it may be possible to provide a framework for indirectly supporting [L]GPL code, but still no tasks directly subject to the Gnu licenses can be included in the Ant CVS tree.

Ant 2 に優れた動的なタスクの組込み機能が加えられると、 間接的に[L]GPLコードをサポートするフレームワークを提供することが可能になるかもしれませんが、 それでもなお、GNU ライセンスに直接帰属するタスクは Ant の CVS ツリーには入れることはできません。

If you link to a GPL or LGPL library, by import or reflection, your task must be licensed under the same terms. So tasks linking to (L)GPL code can't go into the Apache managed codebase. Tasks calling such code can use the 'exec' or 'java' tasks to run the programs, as you are just executing them at this point, not linking to them.

import やリフレクションにより、 GPL や LGPL ライブラリにリンクする場合、 作成したタスクも、同じライセンス条件となります。 ですから、(L)GPL コードにリンクするタスクは、 Apache で管理されるコードベースには入れられないのです。 そのようなコードを呼ぶタスクは、 この点でリンクせずに単に実行するだけなので、 プログラムを実行するために、 'exec' や 'java' タスクを使います。

Even if we cannot include your task into the Apache codebase, we can still point to where you host it -just submit a diff to xdocs/external.html pointing to your task. If your task links directly to proprietary code, we have a differnt problem: it is really hard to build the tasks. Please use reflection.

作成したタスクを Apache コードベースに組み込めないとしても、 そのタスクを置いた場所を参照できます。 つまり、単に、作成したタスクを参照する xdocs/external.html への差分を投稿できます。 作成したタスクが直接、所有権のあるコードへリンクしている場合には、 別の問題があります: このタスクをビルドするのはとても難しいです。 リフレクションを使ってください。

Dont re-invent the wheel

全体を再開発しない

We've all done it: written and submitted a task only to discover it was already implemented in a small corner of another task, or it has been submitted by someone else and not committed. You can avoid this by being aware of what is in the latest CVS tree -keep getting the daily source updates, look at manual changes and subscribe to the ant-dev mailing list.

ここで、全てやり終えました: 別のタスクのほんの一部として既に実装されていたり、 誰かによって投稿され、コミットされていなかったと発見するために タスクを作成し、投稿しました。 日々のソースの更新を取得し続け、 最新の CVS ツリー中に何があるか気づき、 マニュアルの変更を読んだり、 ant-dev メーリングリストを講読することにより、 これを避けることができます。

If you are thinking of writing a task, posting a note on your thoughts to the list can be informative -you well get other peoples insight and maybe some half written task to do the basics, all without writing a line of code.

タスクを作成して、 そのリストが有益であるような、 自分の考えについての注意書きを投稿することを考えれば、 全てのコードを書かなくても、 他の人たちの洞察力がよくわかり、 基本的なことを行うための半分しかできていないタスクを得られるでしょう。

Submitting to Ant

Ant への投稿

The process for submitting an Ant task is documented on the jakarta web site. The basic mechanism is to mail it to the ant-dev mailing list. It helps to be on this list, as you will see other submissions, and any debate about your own submission.

Ant タスクを投稿する手順は、 Jakarta ウェブサイトで記述されています。 基本的なことは、 ant-ev メーリングリストへメールすることです。 このリストに投稿すれば、 他の提案や、あなたの提案についての議論が得られるので、 有益でしょう。

Patches to existing files should be generated with cvs diff -u filename and save the output to a file. If you want to get the changes made to multiple files in a directory , just use cvs diff -u. The patches should be sent as an attachment to a message titled [PATCH] and distinctive one-line summary in the subject of the patch. The filename/task and the change usually suffices. It's important to include the changes as an attachment, as too many mailers reformat the text pasted in, which breaks the patch.

既存のファイルへのタッチは、 cvs diff -u filename により作成し、 その出力をファイルに保存します。 一つのディレクトリ中の複数のファイルに対してなされた変更を得たい場合には、 単に cvs diff -u を使ってください。 パッチは、 [PATCH] というタイトル、および、はっきりわかる一行の要約 をパッチの件名としたメッセージに、 添付ファイルとして送らなければなりません。 ファイル名/タスクおよび、変更点で通常は十分です。 変更を添付ファイルとして入れることが重要です。 多くのメーラーでは、テキストを(本文中に)ペーストしてしまい、 これでは、パッチを壊してしまいます。

Then you wait for one of the committers to commit the patch, if it is felt appropriate to do so. Bug fixes go in quickly, other changes often spark a bit of discussion before a (perhaps revised) commit is made.

そうするのが適切であると感じたならば、 コミッタの一人がパッチをコミットするのを待ちます。 バグ修正はすぐに行われ、 しばしば、他の変更は、 (修正された)コミットが行われるまえに熱い議論となります。

New submissions should be proceeded with [SUBMIT]. The mailer-daemon will reject any messages over 100KB, so any large update should be zipped up. If your submission is bigger than that, why not break it up into separate tasks.

新しい投稿は、[SUBMIT] という件名から始まらなければなりません。 メーラーデーモンは 100KB を超える全てのメッセージを受信拒否します。 ですから、全ての大きな更新は ZIP アーカーブしなければなりません。 投稿がそれよりも大きい場合には、 別々のタスクに分けてください。

We also like submissions to be added to bugzilla, so that they dont get lost. Please submit them by first filing the report with a meaningful name, then adding files as attachments. Use CVS diff files please!

無くならないように、 提案をbugzilla に追加するのも歓迎です。 意味ある名前のレポートを最初に書き込んで、 添付ファイルを加えて投稿してください。 CVS diff ファイルを使ってください。

If you hear nothing after a couple of weeks, remind the mailing list. Sometimes really good submissions get lost in the noise of other issues. This is particularly the case just prior to a new point release of the product. At that time anything other than bug fixes will tend to be neglected.

2 週間ほどたっても何も音沙汰無い場合には、 メーリングリストを思い出してください。 時として、他の問題のノイズに、 良い提案が埋もれてしまうことがあります。 これは、特に新しい製品リリースポイントの前によくあります。 そのようなときは、バグ修正の他の事は無視されがちです。

Checklists

チェックリスト

These are the things you should verify before submitting patches and new tasks. Things don't have to be perfect, it may take a couple of iterations before a patch or submission is committed, and these items can be addressed in the process. But by the time the code is committed, everything including the documentation and some test cases will have been done, so by getting them out the way up front can save time. The committers look more favourably on patches and submissions with test cases, while documentation helps sell the reason for a task.

これらは、 パッチや新しいタスクを投稿する前に、検証しなければならない事です。 これらの事柄は完璧である必要はありません。 パッチや提案がコミットされる前には、 何回かの繰り返しがあります。 これらの項目は手続きの一部なのです。 コードがコミットされる時点では、 ドキュメントや幾つかのテストケースを含む全てが行われていなければなりません。 みんなに見てもらうことにより時間の節約になるでしょう。 ドキュメントによりタスクのメリットがわかるので、 コミッタは、より良いパッチ、 テストケースの提案を探します。

Checklist before submitting a patch

パッチ投稿前のチェックリスト

Checklist before submitting a new task

新しいタスクを投稿する前のチェックリスト


Copyright © 2001-2002 Apache Software Foundation. All rights Reserved.

[訳注:これは漆島賢二が翻訳しました。日本語訳に対するコメントがあれば report@jajakarta.orgに送ってください]