не Java-файлы в структуре пакета

Question

У нас есть разработчик, который имеет привычку фиксировать не-java файлы (xsd, dtd и т. Д.) В пакетах java в папке src / java нашего репозитория. Надо признать, это файлы, относящиеся к этому пакету, но я просто не хочу видеть файлы не-java в папке src.

Это обычная практика, к которой я должен привыкнуть, или мы делаем что-то странное, поддерживая эти файлы вот так?

Answer 1

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

Представьте, что ваше приложение все еще поддерживается в течение 5 или 10 лет командой младших - промежуточных разработчиков, которые сейчас не работают в компании и никогда не будут общаться с теми, кто работает над вашим проектом сейчас. Размещение файлов, тесно связанных с источником, в структуре исходного пакета может облегчить их жизнь.

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

Answer 2

Это очень распространено и даже рекомендуется, если это оправдано. Обычно это оправданно, когда это статический ресурс (DTD + XSLT для проприетарных форматов, готовых сценариев и т. Д.), Но это не так, когда файл может обновляться третьей стороной, например дампом базы данных IP / географического расположения.

Answer 3

Я думаю, что становится легче, если вы думаете, что «src» не означает «исходный код». Думайте об этом как о источнике ресурсов, которые необходимы вашей программе во время компиляции и / или выполнения.

Вещи, которые являются продуктом действий по компиляции или сборке, не должны идти сюда.

По общему признанию, как и большинство вещей, могут применяться исключения:)

Обновление: Лично мне нравится разбивать src дальше с подкаталогами для каждого типа ресурса под ним. Другим может понравиться это разделение на более высоком уровне.

Answer 4

В Eclipse для нас хорошо работает папка src, содержащая классы java, и папка конфигурации (которая называется исходной папкой), содержащая файлы свойств и т. Д. Затем все они вместе попадают в выходную папку и их можно найти в пути к классам, оставаясь в отдельных папках внутри Eclipse

Answer 5

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

Answer 6

Одним из преимуществ хранения всех вспомогательных файлов рядом с исходным кодом является то, что поддерживается согласованность версий между этими сторонними библиотеками и вашим исходным кодом. Если вам когда-нибудь понадобится вернуться и отладить определенную версию, вы можете получить весь набор source + config и сделать так, чтобы все они были одинаковой версии.

Как говорится, я бы положил их в каталог $project/config/ или что-то подобное, а не в $project/src/java. На самом деле они не исходники и не Java, поэтому вводить их в этот каталог вводит в заблуждение.

Когда вы действительно приступаете к этому, это вопрос личного стиля. Нет правильного ответа, и вы должны поговорить с этими членами команды и понять, почему они приняли это решение. Использование этой ветки в качестве доказательства в поддержку одностороннего решения, вероятно, не будет успешным. ;)

Answer 7

Это, конечно, распространено, но невероятно лениво и небрежно. Моя кожа ползет, когда я вижу это.

Использование таких инструментов, как Maven для создания ваших продуктов, позволяет легко и четко отделить код от ресурсов .

Связки Eclipse могут быть разделены аналогичным образом.

Answer 8

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

Answer 9

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