Как вы организуете non-source-ресурсы, доступные на classpath в вашем java-проекте?

Question

В программном проекте, написанном на Java, у вас часто есть ресурсы, которые являются частью проекта и должны быть включены в путь к классам. Например, некоторые шаблоны или изображения, которые должны быть доступны через classpath (getResource). Эти файлы должны быть включены в создаваемый JAR-файл.

Понятно, что эти ресурсы должны быть добавлены в систему контроля версий. Но в какой каталог вы положили эти файлы? Параллельно java-source-files или в другом каталоге, который также воспроизводит необходимую структуру пакета?

Answer 1

Maven помещает их в src / main / resources / (код Java будет идти в src / main / java /). Основная причина в том, что Maven может компилировать код на разных языках, и имеет смысл хранить их отдельно, чтобы одна компиляция не была перепутана файлами с другой.

В случае ресурсов Maven заменит переменные в них, прежде чем они будут добавлены в Jar, поэтому они также являются "скомпилированными" источниками.

Answer 2

Я обычно так:

project/src
project/resources
project/classes
project/lib
project/dist

Оба ресурса src и имеют структуру пакета, а файл сборки принимает классы и ресурсы в качестве входных данных для jar-файла, который помещено в dist .

При внутреннем запуске classpath выглядит примерно так: lib; классы; ресурсы;

Если приложение имеет установку, установщик создает и помещает каталог ресурсов в установку без изменений.

Answer 3

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

С сегодняшними инструментами это тоже не имеет значения. Независимо от того, используете ли вы Eclipse, Netbeans или другой инструмент, все они позволяют вам иметь бинарные пакеты с компоновкой, отличной от исходного кода. Таким образом, в конце концов, вы можете сделать это, как вы хотите.

Лично я стараюсь не смешивать источник с ресурсами, потому что я обычно меняю ресурсы очень редко, но исходный код очень часто.

Answer 4

Я предпочитаю ваше последнее решение: отдельный каталог, который имитирует структуру пакета исходного кода. Таким образом, они не будут засорять ваш исходный код, но будут рядом с скомпилированными файлами классов в упакованном файле JAR.

Answer 5

Лично я предпочел бы иметь их вместе с исходным кодом, если они тесно связаны с конкретными частями кода, и если их не слишком много.

Но если для этих файлов имеет смысл иметь собственную организационную структуру или если существуют сотни файлов, из-за которых сложно найти среди них исходный код, я бы оставил их отдельно.

Answer 6

Как уже говорилось, это зависит от вас и может отличаться в зависимости от проекта. Например, для Wicket вполне обычно и практично хранить файлы .html рядом с классами. Кроме того, я часто храню некоторые настройки вместе с исходным кодом - META-INF, WEB-INF, ведение журнала.

Чтобы Maven брал ресурсы из дерева исходных текстов, используйте это:

<build>
   <resources>
     <resource>
         <directory>src/main/resources</directory>
     </resource>
     <!-- Web - Wicket -->
     <resource>
         <filtering>false</filtering>
         <directory>src/main/java</directory>
         <includes><include>**</include></includes>
         <excludes><exclude>**/*.java</exclude></excludes>
     </resource>
  </resources>

  <testResources>
     <testResource>
         <directory>src/test/resources</directory>
     </testResource>
     <!-- Web - Wicket -->
     <testResource>
         <filtering>false</filtering>
         <directory>src/main/java</directory>
         <includes><include>**</include></includes>
         <excludes><exclude>**/*.java</exclude></excludes>
     </testResource>
  </testResources>

Основной причиной разделения ресурсов является (imho) разделение рабочих ролей. Например. если у вас есть проект с командами переводчиков, вы будете хранить ресурсы со строками отдельно от кода и с другими привилегиями SCM.

Answer 7

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

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