Почему ресурсы макета проекта хранятся отдельно от источников Java?

Почему maven хранит ресурсы в отдельной "исходной папке" из источников Java?

По моему опыту, в Java файлы ресурсов в основном обрабатываются как исходные файлы Java, которые при компиляции просто должны быть скопированы как есть с классами и, в конечном итоге, упакованы в банку и доступны загрузчику классов методы getResource/getResourceAsStream, через classpath.

Лично я считаю бесполезной сложность хранить файлы ресурсов отдельно от источников Java.

  • Как вы думаете?
  • Есть ли веская причина, по которой maven сохраняет ресурсы отдельно от источников?
  • Есть ли индикация счетчика при использовании src/main/resources и src/test/resources и сохранении ресурсов в src/main/java и src/test/java с помощью maven?

ОТВЕТЫ

Ответ 1

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

  • SRC/основная
    • Ресурсы
    • ява
    • groovy

каждый субдир имеет определенную классификацию файлов:

  • java → вещи, которые скомпилированы как java файлы
  • groovy → вещи, которые скомпилированы как groovy scripts
  • resources → нескомпилированные данные, используемые для любого... (также они могут быть отфильтрованы для добавления информации о времени компиляции)

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

Ответ 2

для простоты и упрощения доступа мы сохраняем некоторые ресурсы также в пути источника java. Это делает его удобным для нас при разработке на уровне графического интерфейса пользователя в качестве шаблонов скорости, и они близки к Java-коду контроллера. Но вы должны сказать maven, чтобы включить в него файл java, который находится в src/main/java, добавив что-то подобное вашему файлу pom.

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.1.1</version>
                <configuration>
                <webResources>
                    <resource>
                        <directory>src/main/java</directory>
                        <targetPath>WEB-INF/classes</targetPath>
                      <includes>
                        <include>**/*.properties</include>
                        <include>**/*.xml</include>
                        <include>**/*.htm</include>
                        <include>**/*.html</include>
                        <include>**/*.css</include>
                        <include>**/*.js</include>
                      </includes>
                    </resource>
                    <resource>
                        <directory>src/main/resources</directory>
                      <excludes>
                        <exclude>**/log4j.xml</exclude>
                      </excludes>
                    </resource>
                </webResources>
                </configuration>
            </plugin>

Ответ 3

Как вы думаете? Я думаю, что ребятам, стоящим за Maven, следует немного "разобраться в проблемах". Причина номер один для использования Maven заключается в управлении зависимостями, но почему блендер говорит мне, как очистить мои фрукты? Мне это вообще не имеет смысла.

Есть ли веская причина, почему maven хранит ресурсы отдельно от источников? Нет. В проекте java дублирование структуры пакета не один, а три раза добавляет ненужную работу в проект, увеличивая риск ошибок и уменьшая гибкость кода.

Ответ 4

Я пытаюсь дать ответ сам.

Как вы думаете?

Это бесполезная дополнительная сложность. Таким образом, неверно: см. Ниже.

Есть ли веская причина, по которой maven хранит ресурсы отдельно от источников?

Единственная причина, по которой я мог бы подумать, - это то, что для некоторой платформы это может быть хорошей практикой. Например, в приложении Mac OSX ресурсы упаковываются отдельно (в другой подпапке), чем в двоичные файлы.

Я думаю, что "внешние" ресурсы и файлы конфигурации, те, которые не попадают в финальный артефакт (файл jar), могут иметь вескую причину для сохранения отдельно от исходных файлов. Итак, когда maven упаковывает банку, он знает, что эти файлы не обязательно должны быть включены, потому что, например, мы хотим, чтобы они были за пределами банки, чтобы позволить пользователю редактировать эти файлы в качестве конфигурации.

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

Ресурсы могут быть организованы с той же структурой пакета, что и для классов, поэтому, если у вас есть класс в пакете xyz, вы можете захотеть иметь ресурсы, от которых он зависит, в том же пакете, поскольку они представляют один и тот же "логический блок" ": в этом случае наличие их в двух отдельных папках приводит к дополнительному вниманию, требуемому при реорганизации и реорганизации пакета, поскольку вы хотите синхронизировать данные. КлассLoader также предоставляет возможность указывать относительные пути в методе getResourceAsStream(). Итак, если у вас есть класс x.y.z.MyClass, вы можете сделать getClass(). GetResourceAsStream (" foo-bar.properties "), а ресурсы будут загружены из одного пакета" x.y.z". Поэтому очень полезно держать вещи вместе, когда у них плотная зависимость.

Для внешних ресурсов, которые необходимо сохранить отдельно и в развертываемом артефакте, хорошо держать их отдельно, но в этом случае я не понимаю, почему maven рассматривает src/main/resources как "исходная папка java" (maven-eclipse-plugin), поскольку они фактически не должны находиться в пути к классам, но доступны через файловую систему как обычные файлы, и особенно вы не хотите, чтобы эти файлы были включены в банку во время сборки maven. Это относится к значкам приложений, файлам конфигурации, которые вы, возможно, захотите поместить в каталог /etc, и т.д.

В заключение, что-то неправильно в том, как maven обрабатывает ресурсы, на мой взгляд: если они являются "внешними" ресурсами, тогда нет причин, по которым maven упаковывает их в финальный артефакт (jar). Если они не являются "внешними", тогда нет причин держать их в отдельной "исходной папке".

Есть ли индикация счетчика при использовании src/main/resources и src/test/resources и хранении ресурсов в src/main/java и src/test/java с помощью maven?

Я не знаю.

В большинстве случаев я использовал по умолчанию maven layout, чтобы играть с ресурсами, но пару раз я этого не делал; принимая меры предосторожности, чтобы объявить местоположение каталога нестандартных ресурсов в pom (см. resources и супер-П). Можно изменить структуру каталога проекта maven, указав, что в pom:

 <build>
    <directory>target</directory>
    <outputDirectory>target/classes</outputDirectory>
    <finalName>${artifactId}-${version}</finalName>
    <testOutputDirectory>target/test-classes</testOutputDirectory>
    <sourceDirectory>src/main/java</sourceDirectory>
    <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
    <testSourceDirectory>src/test/java</testSourceDirectory>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
      </resource>
    </resources>
    <testResources>
      <testResource>
        <directory>src/test/resources</directory>
      </testResource>
    </testResources>
  </build>

И я не нашел в нем особых проблем.

Я хотел бы, чтобы ребята из maven снова подумали об этом соглашении, поскольку более простая структура проекта помогает разработчику больше сосредоточиться на разработке и меньше на поиск вещей вокруг нескольких папок в структуре проекта при просмотре кода приложения.

Ответ 5

То, как я различаю эти два, заключается в том, что по умолчанию папки java не позволяют создавать ничего в полученном банке, за исключением типов файлов, которые я перечисляю (например, *.class, *.html, *.properties, если вы 're using Wicket), тогда как все вещи в resources будут скопированы в сборке, за исключением нескольких исключений, которые я перечисляю.

Конечно, это только мое личное соглашение, которое я придерживался сам.

Ответ 6

1) Что вы думаете?

Я думаю, это отличная конвенция.

2) Есть ли веская причина, по которой maven сохраняет ресурсы отдельно от источников?

Да. Вы следуете конвенции. Каждый, у кого есть доступ к вашему проекту, будет знать, где искать код и где для всего остального. И конечно, где для тестовых случаев. И что произойдет с каким файлом, когда этот плагин будет выполнен.

3) Есть ли индикация счетчика при использовании src/main/resources и src/test/resources и хранении ресурсов в src/main/java и src/test/java с помощью maven?

Нет счетчика. Это вопрос конвенции, ничего плохого в том, как вы упорядочиваете свой собственный код. На самом деле, если вы когда-либо создавали проект Wicket, вы увидите свой HTML-код, и ваш Java-код останется бок о бок в Java-пакете. Но, это просто Wicket, где вы знаете, что HTML будет рядом с файлами Java. Но все остальное идет в папке resources.

Ответ 7

Может быть, я единственный, кто пришел из фона Java. Я думаю, что смешивание ресурсов и кода очень грязно. Разделение забот делает ваш проект более чистым и понятным/поддерживающим по мере его роста.

Я пытаюсь применить свое собственное соглашение о каталогах ко всем моим проектам разработки программного обеспечения:

  • bin: окончательные двоичные файлы, используемые пользователем
  • build: промежуточные двоичные файлы, они могут быть удалены после сборки
  • lib: внешние библиотеки
  • src: ТОЛЬКО исходный код (в данном случае исходные файлы Java)
  • ресурсы: все ресурсы (файлы конфигурации, xmls, images, html и т.д.)
  • docs: documentation

Редко я нашел контекст разработки, когда мне нужно было изменить эту структуру каталогов.

Используя Maven, если вы хотите сделать быструю настройку, используйте настройки по умолчанию. Если вы хотите использовать соглашение с вашим каталогом, вам просто нужно изменить настройки в pom.xml, как описано ранее. Имейте в виду, однако, что некоторые плагины Maven считают, что вы используете каталоги Maven по умолчанию для ресурсов/исходных/выходных двоичных файлов, и вам придется настроить некоторые параметры плагина, если вы измените эти каталоги.

Ответ 8

Я думаю, что разделение кода/ресурсов часто полезно:

  • Пакеты должны соответствовать правилам спецификации Java, например зарезервированное слово, например 'int', не допускается. Нелегальные пакеты в папке исходного кода будут путать.

  • Ресурсы имеют природу экземпляра, классы имеют, ну, классы природы. Например, у вас могут быть классы Continent и Country в одном пакете, но ресурсы лучше упорядочиваются как дерево:

    • африки /
      • morocco.txt
      • kenya.txt
    • Европа /
      • poland.txt

  • Структура ресурсов, на мой взгляд, более стабильна, чем структура кода. Частое рефакторинг кода происходит часто, классы переходят из пакета в пакет для лучшей удобочитаемости. Обязательство переместить ресурсы на рефакторинг препятствует разработчику из рефакторинга.

  • Если разделенная папка ресурса требуется даже для 1% файлов ресурсов, разумно переместить оставшиеся 99% в эту папку и сохранить ресурсы только в одном месте.

Однако существуют случаи, когда хранение ресурсов и Java-код вместе полезны. Например, модульные тесты сравнивают ввод и вывод - приятно иметь файл с вводом и выводом в той же папке, что и unit test.