Eclipse Javaプロジェクトフォルダー編成
JavaとEclipseにC＃/ Visual Studioのバックグラウンドから来ています。後者では、通常、次のようなソリューションを編成します。
\ MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff
ここで、MyAppは.exeをビルドするプロジェクトを含み、MyAppsUtilitiesは.exeによって呼び出されるAssembly DLLを作成し、LowerLevelStuffはより高レベルのユーティリティDLLによって使用されるクラスを含むアセンブリをビルドします。
Eclipseで（Ganymede、しかしGalileoに切り替えると確信できる）私は持っています：
\ MyProjects\workspace\MyApp
最初のプロジェクトを作成するとき。ソースファイルとビルドファイルを同じフォルダーに配置するオプションがありますが、パッケージ階層を反映したパスに.Javaファイルが作成されています。
\ MyProjects\workspace\MyApp\src\com\mycompany\myapp\MyApp.Java
私の質問はこれです：.NETファイルの上記のMyAppsUtilitiesおよびLowerLevelStuffアセンブリDLLに類似する.jarファイルのサブプロジェクト（正しいJava/Eclipse用語ですか？）を作成するとき、同等にフォルダーを整理できますか（すべきです）？例えば。：
\ MyProjects\workspace\MyApp\src\com\mycompany\myapp\myapputilities\MyAppsUtilities.Java
このようなものを整理するための標準的/正しい方法は何ですか？IDEでどのように具体的に行われますか？
Javaソースコードパッケージを1つの大きな階層名前空間と考えてください。商用アプリケーションは通常「com.mycompany.myapp」の下にあります（このアプリケーションのWebサイトは「http://myapp.mycompany.com 'ですが、これは必ずしもそうとは限りません）。
Myappパッケージの下にあるものを整理する方法は、主にあなた次第です。 C＃に対して実行可能ファイル（.exe）、DLL、低レベルクラスを区別することは、Javaの同じ形式には存在しません。すべてのJavaソースコードは、多くのプラットフォームのJava仮想マシン（JVM）で実行できる.classファイル（その内容は「バイトコード」と呼ばれます）にコンパイルされます。したがって、パッケージを介してそのようなレベルを指定しない限り、高レベル/低レベルクラスに固有の区別はありません。パッケージングの一般的な方法は次のとおりです。
- com.mycompany.myapp：メインクラス; MyApp（メインメソッドを使用）
- com.mycompany.myapp.model：ドメインモデルクラス;顧客、注文など.
- com.mycompany.myapp.ui：ユーザーインターフェイス（プレゼンテーションまたはビュー）コード
- com.mycompany.myapp.service：アプリケーション内のサービス、つまり「ビジネスロジック」
- com.mycompany.myapp.util：いくつかの場所で使用されるヘルパークラス
これはスタンドアロンのJavaアプリを示唆していますが、多くのフレームワークのいずれかを使用するWebアプリの場合は異なる場合があります。
これらのパッケージは、プロジェクトのディレクトリ階層に対応しています。 Eclipseを使用する場合、このような階層のルートは「ソースディレクトリ」と呼ばれます。プロジェクトは、複数のソースディレクトリ、通常は「メイン」および「テスト」ソースディレクトリを定義できます。
プロジェクト内のファイルの例：
src/test/Java/com/acme/foo/BarTest.Java
src/main/Java/com/acme/foo/Bar.Java
lib/utilities_1_0.jar
そして、utilities_1_0.jar内：
com/acme/foo/BarUtils.class
BarUtils.classこれはコンパイルされたJavaクラスなので、任意のJVMで実行できるプラットフォームに依存しないバイトコード形式です。通常、jarファイルにはコンパイルされたクラスのみが含まれますが、ソース（.Java）ファイルも含まれるバージョンのjarをダウンロードすることもできます。これは、使用しているjarファイルの元のソースコードを読み取れるようにする場合に便利です。
上の例では、Bar、BarTest、およびBarUtilsはすべて同じパッケージcom.acme.fooにありますが、物理的にはハードディスクの異なる場所にあります。
ソースディレクトリに直接存在するクラスは「デフォルトパッケージ」にあります。クラスがどの会社やアプリケーションに属しているかが明確ではなく、jarファイルがある場合は名前の競合が発生する可能性があるため、通常はそこにクラスを保持することはお勧めできませんクラスパスに追加すると、デフォルトパッケージに同じ名前のクラスが含まれます。
このアプリケーションをデプロイすると、通常は.classファイルにコンパイルされ、.jarにバンドルされます（これは基本的に.Zipファイルとマニフェスト情報のファンシーな名前です）。 .jarを作成することは、アプリケーションを実行するために必要ではありませんが、アプリケーションをデプロイ/配布するときに便利です。マニフェスト情報を使用すると、.jarファイルを「実行可能」にして、ユーザーが簡単に実行できるようにすることができます（[a]を参照）。
通常、いくつかのライブラリ、つまりインターネットから取得した既存の.jarファイルも使用します。非常に一般的な例は、log4j（ロギングフレームワーク）またはデータベースなどにアクセスするためのJDBCライブラリです。また、個別のjarファイル（上記の「utilities_1_0.jar」など）にデプロイされた独自のサブモジュールがある場合があります。 jarfileで物事を分割する方法は展開/配布の問題であり、それらはすべてJavaソースコードのユニバーサルネームスペースを共有しています。したがって、実際には、必要に応じてすべてのjarfileを解凍し、1つの大きなディレクトリ構造にコンテンツを配置できます（ただし、通常はそうしません）。
複数のライブラリを使用/構成するJavaアプリケーションを実行すると、一般に「クラスパスヘル」と呼ばれるものに遭遇します。私たちが知っているJavaの最大の欠点の1つ。 （注：ヘルプはおそらく 途中です ）。コマンドラインでJavaアプリケーションを実行するには（つまり、Eclipseからではありません）、クラスパス上のすべての.jarファイルの場所を指定する必要があります。 Javaの多くのフレームワーク（Maven、Spring、OSGi、Gradle）の1つを使用している場合、通常、この痛みを軽減するための何らかの形のサポートがあります。 Webアプリケーションを構築している場合、一般にそのレイヤー化/展開規則を順守するだけで、選択したWebコンテナー（Tomcat、Jetty、Glassfish）に物を簡単に展開できます。
これにより、Javaでの動作についての一般的な洞察が得られることを願っています
[a] MyAppアプリケーションの実行可能jarを作成するには、パスにJDKが必要です。次に、コンパイル（binまたはターゲット）ディレクトリで次のコマンドラインを使用します。
jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp
その後、コマンドラインから次のコマンドを実行できます。
Java -jar myapp.jar
または、jarファイルをダブルクリックします。その場合Javaコンソールは表示されないので、これは独自のGUI（Swingアプリなど）を持つアプリケーションまたはバックグラウンド（ソケットサーバーなど）で実行されるアプリケーションにのみ有用です。
Mavenには、よく考えられた 標準ディレクトリレイアウト があります。 Mavenを直接使用していない場合でも、これを事実上の標準と考えることができます。 Mavenの「マルチモジュール」プロジェクトは、説明した.netの複数アセンブリレイアウトにかなり類似しています。
この質問に答える前に、明確にする必要があることが2つあります。
- どのソースコードリポジトリを使用しますか？
- Eclipseの外部で成果物を自動的にビルドするために、どのビルドシステムを使用しますか？
答えはあなたのオプションに強く影響します。
ライブラリーまたは完成した実行可能/実行可能jarのいずれかである「1つのEclipseプロジェクトprコンポーネント」を選択しました。これにより、Hudsonによる自動化が簡単になりました。単一のプロジェクトには複数の責任がないため、CVSの使用も簡単です。
各プロジェクトには、たとえばJava source。
通常、Eclipseで異なるプロジェクトとして関連/サブプロジェクトを作成します。