Организация папок проекта Eclipse Java

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

\MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff

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

В Eclipse (Ганимед, но можно убедиться, чтобы переключиться на Галилео) у меня есть:

\MyProjects\рабочее пространство \MyApp

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

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

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

\MyProjects\рабочей\MyApp\SRC\ком\MyCompany\MyApp\myapputilities\MyAppsUtilities.java

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

Ответ 1

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

Как вы упорядочиваете материал под своим пакетом myapp, в значительной степени зависит от вас. Различие, которое вы выполняете для С# между исполняемыми (.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, который вы добавляете в свой путь к классу, содержит класс с таким же именем в пакете по умолчанию.

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

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

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

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

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

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

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

java -jar myapp.jar

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

Ответ 2

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

Ответ 3

Есть две вещи, которые вам нужно прояснить, прежде чем ответить на этот вопрос:

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

Ответы будут сильно влиять на ваши варианты.

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

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

Ответ 4

Как правило, вы должны создавать связанные/sub-проекты как разные проекты в Eclipse.