デバッグ時にコードをステップスルーする機能を支援するために、ソースコードを含むようにJARファイルを作成することをお勧めします。どのような問題が発生する可能性があるのでしょうか。私がすぐに思ったのは、JARファイルは少し大きくなるだろうということでした。私はそれと一緒に暮らすことができます。他に考慮する必要のある問題はありますか?
TIA
デバッグ時にコードをステップスルーする機能を支援するために、ソースコードを含むようにJARファイルを作成することをお勧めします。どのような問題が発生する可能性があるのでしょうか。私がすぐに思ったのは、JARファイルは少し大きくなるだろうということでした。私はそれと一緒に暮らすことができます。他に考慮する必要のある問題はありますか?
TIA
通常、コンパイルされたコードとソースコードを2つの異なるjarに分けます。
次に、コードをデバッグする必要があるときに、IDEにソースコードjarをアタッチできます。
Mavenのようなビルドツールはあなたのためにそれを簡単に行います。
私はそれを強くお勧めします。私はこれを行い、いくつかのオープンソースプロジェクト(jMock、Hamcrest、GWTなど)も行います。
これにより、個別のソースjarを使用する手間が省けます。また、将来のある時点でソースプロジェクトが失われた場合(大規模な組織で発生する場合もあります)、将来のメンテナンスプログラマーはそれを再作成する可能性が高くなります。
jarにアクセスできる人があなたのソースコードを見ることができ、jarサイズの増加(およびjarの作成、転送、展開にかかる時間のおそらく無視できる増加)のペナルティを支払う準備ができていることに満足している場合は、心配する必要があるのはそれだけです。私の知る限り、他に問題はありません。
Maven標準がソースファイルを分離しておくことであるからといって、そのようにする必要があるという意味ではありません。
通常、別のソース.jarを作成します。Mavenはこれを簡単に作成でき、IDEはこれらにアクセス/ダウンロードする方法を知っています。
Javaスペースの一部のツールは、クラスパスから(つまり、jar内から)ソースファイルを取得し、厄介なことを行います。
通常、これが表示されるのは、これを行うjarに依存関係を追加した場合です...その後、これらのソースファイルが依存プロジェクトに再度コンパイルされ、そのjarにバンドルされ、クラスが取得すると、すべてのクラスローダーの地獄が解き放たれます。あるソースと別のソースからロードされます。
ただそれをしないでください。Mavenの方法に従い(Mavenを使用していない場合でも)、別の方法を作成します-sources.jar