Я пытаюсь дать ответ самостоятельно.
Как вы думаете?
Это бесполезная дополнительная сложность.Таким образом, это неправильно: см. Ниже.
Есть ли веская причина, по которой maven хранит ресурсы отдельно от источников?
Единственная причина, по которой я могу подумать, заключается в том, что для некоторыхПлатформа это может быть хорошей практикой.Например, в приложении Mac OSX ресурсы упакованы отдельно (в другой подпапке), чем двоичные файлы.
Я думаю, что "внешние" ресурсы и файлы конфигурации, те, которые не упакованы в финальный артефакт (файл jar), могут иметь веские основания для того, чтобы их не связывали с исходными файлами.Поэтому, когда maven упаковывает jar-файл, он знает, что эти файлы не нужно включать, потому что, например, мы хотим, чтобы они были вне jar-файла, чтобы пользователь мог редактировать эти файлы как конфигурацию.
Но для вещей, которые упакованы вместе в jar (например, строки перевода и метаданные xml, такие как отображения гибернации и конфигурация пружины), нет веских причин хранить их в отдельном месте, если только мы не ожидаем, что наши пользователи их изменят.вручную после развертывания, как часть процесса настройки.
Ресурсы могут быть организованы с той же структурой пакета, что и для классов, поэтому, если у вас есть класс в пакете xyz, вы можете захотеть иметь ресурсы, которые у него есть.зависит от одного и того же пакета, так как они представляют одну и ту же «логическую единицу»: в этом случае их размещение в двух отдельных папках требует дополнительного внимания, необходимого при рефакторинге и реорганизации пакета, так как вы хотите поддерживать синхронизацию.ClassLoader также предоставляет возможность указывать относительные пути в методе getResourceAsStream ().Поэтому, если у вас есть класс xyzMyClass, вы можете сделать getClass (). GetResourceAsStream ("foo-bar.properties"), и ресурсы будут загружены из того же пакета "xyz".Поэтому очень полезно хранить вещи вместе, когда они сильно зависимы.
Для внешних ресурсов, которые необходимо хранить отдельно, также в развертываемом артефакте, это хорошая вещь, чтобы хранить ихотдельно, но в этом случае я не понимаю, почему maven рассматривает src / main / resources как «исходную папку java» (maven-eclipse-plugin), поскольку они на самом деле не должны находиться в пути к классам, а доступ к ним осуществляется через файловую систему как простойфайлы, и особенно вы не хотите, чтобы эти файлы были включены в jar во время сборки maven.Это случай значков приложений, файлов конфигурации, которые вы, возможно, захотите поместить в каталог / etc, и т. Д.
В заключение, что-то не так в том, как maven обрабатывает ресурсы, по моему мнению: если они«внешние» ресурсы, то нет причин, по которым maven упаковывает их в конечный артефакт (jar).Если они не являются «внешними», то нет смысла хранить их в отдельной «исходной папке».
Есть ли какие-либо указания на счетчики при неиспользовании src / main / resources и src / test/ resources и хранение ресурсов в src / main / java и src / test / java с использованием maven?
Не знаю.
Большую часть времени я использовал макет по умолчанию maven для игры с ресурсами, но пару раз я этого не делал;принять меры предосторожности для объявления нестандартного расположения каталога ресурсов в pom (см. resources и super-pom ).Можно изменить структуру каталогов проекта 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 подумали еще разоб этом соглашении, поскольку наличие более простой структуры проекта помогает разработчику больше сосредоточиться на разработке и меньше на поиске элементов в нескольких папках в структуре проекта при просмотре кода приложения.