Eclipse Java организация папок проекта - PullRequest
28 голосов
/ 02 октября 2009

Я перехожу на Java и Eclipse из C # / Visual Studio. В последнем случае я бы обычно организовывал решение так:

\ MyProjects \ MyApp \ MyAppsUtilities \ LowerLevelStuff

, где MyApp будет содержать проект для сборки .exe, MyAppsUtilities создаст DLL-сборку, вызываемую .exe, а LowerLevelStuff, вероятно, создаст сборку, содержащую классы, используемые DLL-библиотеками утилит более высокого уровня.

В «Затмении» (Ганимед, но меня убедили перейти на Галилео), у меня есть:

\ MyProjects \ рабочее место \ MyApp

Когда я создаю свой первоначальный проект. Существует возможность поместить исходные файлы и файлы сборки в одну и ту же папку, но у меня есть файлы .java, созданные по пути, который отражает мою иерархию пакетов:

\ MyProjects \ рабочее место \ MyApp \ SRC \ ком \ MyCompany \ MyApp \ MyApp.java

У меня такой вопрос: когда я создаю подпроекты (это правильный термин Java / Eclipse?) Для файлов .jar, которые будут аналогичны вышеуказанным сборочным DLL MyAppsUtilities и LowerLevelStuff в .NET, могу (должен) ли я организовать папки эквивалентно? E.g.:

\ MyProjects \ рабочее пространство \ MyApp \ SRC \ ком \ MyCompany \ MyApp \ myapputilities \ MyAppsUtilities.java

Каков стандартный / правильный способ организации этого материала и как это конкретно делается в IDE?

Ответы [ 4 ]

55 голосов
/ 02 октября 2009

Думайте о пакетах исходного кода Java как об одном большом иерархическом пространстве имен. Коммерческие приложения обычно находятся под com.mycompany.myapp (веб-сайт для этого приложения может быть http://myapp.mycompany.com', хотя, очевидно, это не всегда так).

Как вы организовываете вещи в пакете myapp, в значительной степени зависит от вас. Различие, которое вы делаете для C # между исполняемым файлом (.exe), DLL и низкоуровневыми классами, не существует в той же форме в Java. Весь исходный код Java скомпилирован в файлы .class (содержимое которых называется «байт-кодом»), которые могут выполняться виртуальной машиной Java (JVM) на многих платформах. Таким образом, нет никаких внутренних различий между классами высокого уровня и низкого уровня, если только вы не приписываете эти уровни через свою упаковку. Обычный способ упаковки:

  • com.mycompany.myapp : основной класс; MyApp (с основным методом)
  • com.mycompany.myapp.model : классы модели предметной области; Заказчик, заказ и т. Д.
  • com.mycompany.myapp.ui : код пользовательского интерфейса (представление или представление)
  • com.mycompany.myapp.service : сервисы в вашем приложении, т. Е. «Бизнес-логика»
  • com.mycompany.myapp.util : вспомогательные классы, используемые в нескольких местах

это предполагает отдельное Java-приложение, оно может отличаться, если это веб-приложение, использующее одну из множества сред.

Эти пакеты соответствуют иерархии каталогов в вашем проекте. При использовании 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. Обычно jarfiles содержат только скомпилированные классы, хотя иногда вы можете скачать версию jar, которая также содержит исходные файлы (.java). Это полезно, если вы хотите иметь возможность прочитать исходный код используемого вами файла JAR.

В приведенном выше примере Bar, BarTest и BarUtils находятся в одном пакете com.acme.foo, но физически находятся в разных местах на жестком диске.

Классы, которые находятся непосредственно в исходном каталоге, находятся в «пакете по умолчанию», обычно не стоит хранить там классы, потому что неясно, к какой компании и приложению относится класс, и вы можете получить конфликты имен, если любой jar-файл, который вы добавляете в classpath, содержит класс с тем же именем в пакете по умолчанию.

Теперь, если вы развернете это приложение, оно, как правило, будет скомпилировано в файлы .class и упаковано в .jar (что по сути является необычным именем для файла .zip плюс некоторая информация о манифесте). Создание .jar не обязательно для запуска приложения, но удобно при развертывании / распространении вашего приложения. Используя информацию манифеста, вы можете сделать файл .jar «исполняемым», чтобы пользователь мог легко его запустить, см. [A].

Обычно вы также будете использовать несколько библиотек, т.е. существующие файлы .jar, полученные из Интернета. Очень распространенными примерами являются log4j (каркас журналирования) или библиотеки JDBC для доступа к базе данных и т. Д. Также у вас могут быть собственные субмодули, которые развернуты в отдельных jar-файлах (например, «utilities_1_0.jar» выше). То, как вещи распределяются по jarfiles, является вопросом развертывания / распространения, они все еще имеют общее пространство имен для исходного кода Java. Таким образом, вы можете разархивировать все jar-файлы и поместить содержимое в одну большую структуру каталогов, если хотите (но обычно это не так).

При запуске приложения Java, которое использует / состоит из нескольких библиотек, вы сталкиваетесь с тем, что обычно называют «адом Classpath». Один из самых больших недостатков Java, как мы его знаем. (примечание: помощь предположительно в пути ). Чтобы запустить приложение Java в командной строке (то есть не из Eclipse), вы должны указать каждое местоположение файла .jar в пути к классам. Когда вы используете одну из многих фреймворков Java (Maven, Spring, OSGi, Gradle), обычно есть некоторая поддержка, чтобы облегчить эту боль. Если вы создаете веб-приложение, вам, как правило, нужно просто придерживаться его соглашений о размещении и развертывании, чтобы иметь возможность легко развернуть объект в веб-контейнере по вашему выбору (Tomcat, Jetty, Glassfish).

Надеюсь, это даст общее представление о том, как все работает в Java!

[a] Чтобы создать исполняемый jar-файл приложения MyApp, вам нужен JDK на вашем пути. Затем используйте следующую командную строку в каталоге компиляции (bin или target):

jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp

Затем вы можете выполнить его из командной строки с помощью:

java -jar myapp.jar

или двойным щелчком по файлу jar. Обратите внимание, что в этом случае вы не увидите консоль Java, поэтому это полезно только для приложений, которые имеют собственный графический интерфейс (например, приложение Swing) или могут работать в фоновом режиме (например, сервер сокетов).

9 голосов
/ 02 октября 2009

Maven имеет хорошо продуманную стандартную структуру каталогов . Даже если вы не используете его Maven напрямую, вы можете думать об этом как о стандарте де-факто. Проекты с несколькими модулями Maven являются хорошей аналогией описанной вами компоновки компоновки .net.

2 голосов
/ 02 октября 2009

Прежде чем ответить на этот вопрос, необходимо уточнить две вещи:

  1. Какой репозиторий исходного кода вы будете использовать?
  2. Какую систему сборки вы будете использовать для автоматического создания артефактов вне Eclipse?

Ответы сильно повлияют на ваши варианты.

Мы выбрали «один компонент pr проекта Eclipse», который может быть либо библиотекой, либо готовым исполняемым / исполняемым jar Это позволило легко автоматизировать работу с Hudson. Наше использование CVS также проще, так как отдельные проекты не имеют нескольких обязанностей.

Обратите внимание, что каждый проект может содержать несколько исходных папок, разделяющих, например, тестовый код из конфигурации из исходного кода Java. Это не так важно, как упрощение вашей структуры.

1 голос
/ 02 октября 2009

Обычно в Eclipse вы создаете связанные / вспомогательные проекты как разные проекты.

...