У нас есть разработчик, который имеет привычку совершать не-java файлы (xsd, dtd и т.д.) в пакетах java в папке src/java в нашем репозитории. По общему признанию, это релевантные файлы для этого пакета, но мне просто не нравится видеть файлы, отличные от java, в папке src.
Является ли это обычной практикой, к которой я должен привыкнуть или что-то странное, поддерживая эти файлы следующим образом?
Проблема с размещением файлов не Java (или других языков), которые тесно связаны с кодом в другом месте, чем код, - это знать, где их найти. Можно стандартизировать места, тогда теоретически каждый будет знать, куда идти и что делать. Но я нахожу на практике, что этого не происходит.
Представьте, что ваше приложение все еще поддерживается через 5 или 10 лет от команды разработчиков младших классов - промежуточных разработчиков, которые сейчас не работают в компании и никогда не будут разговаривать со всеми, кто работает над вашим проектом. Помещение файлов, тесно связанных с источником в структуре исходного пакета, могло бы облегчить их жизнь.
Я большой сторонник устранения как можно большего числа двусмысленностей в разумных пределах.
Это очень часто и даже рекомендуется, если это оправдано. В целом это оправдано, когда это статический ресурс (DTD + XSLT для проприетарных форматов, готовые скрипты и т.д.), Но это не когда файл является тем, что может быть обновлено третьей стороной, такой как дамп базы данных IP/географического местоположения.
Мне кажется, вам становится легче, если вы думаете о 'src', поскольку это не означает "исходный код". Подумайте об этом как о источнике ресурсов, которые необходимы вашей программе во время компиляции и/или времени выполнения.
Вещи, которые являются продуктом для компиляции или сборки, не должны здесь идти.
По общему признанию, как и большинство вещей, исключения могут применяться:)
Update: Лично мне нравится разбивать src далее на подкаталоги для каждого типа ресурсов под ним. Другие могут любить это разделение на более высоком уровне.
Существует много библиотек jar, которые используют ту же практику. Я думаю, что это приемлемо и удобно.
В Eclipse это хорошо работает для нас, чтобы иметь папку src, содержащую классы Java, и папку конфигурации (которая благословлена как исходная папка), содержащую файлы свойств и т.д. Затем все они вместе идут в выходной папке и могут быть найдены в пути к классам, все еще находясь в отдельных папках внутри Eclipse
Одним из преимуществ хранения всех вспомогательных файлов рядом с источником является то, что согласованность версий поддерживается между этими сторонними библиотеками и исходным кодом. Если вам когда-нибудь понадобится вернуться и отладить определенную версию, вы можете вытащить весь набор исходных файлов + config и все это будет одна и та же версия.
Говоря, что я поместил их в каталог $project/config/ или какой-то такой, а не в $project/src/java. Они не являются источником, а не java, поэтому он вводит в заблуждение их наличие в этом каталоге.
Если вы действительно приступите к этому, это проблема личного стиля. Там нет "правильного" ответа, и вы должны поговорить с этими членами команды и понять, почему они приняли это решение. Использование этой темы в качестве доказательства для поддержки одностороннего решения, вероятно, не пройдет хорошо.;)
Его довольно часто, вы можете найти его в действительно популярных фреймворках, например. xsd для spring различных схем. Также люди обычно размещают файлы сопоставления спящего режима в том же пакете, что и классы модели.
Я думаю, что это распространено до тех пор, пока файлы необходимы. Проблемы возникают, когда люди начинают делать файлы, которые не нужны с источником, такие как конструкторские спецификации или случайные текстовые файлы.
Это, конечно, обычное дело, но невероятно ленивое и неряшливое. Моя кожа ползет, когда я это вижу.
С помощью инструмента, такого как Maven для создания ваших продуктов, вы можете легко и четко выделить код из ресурсов.
Связки Eclipse могут быть разделены аналогичным образом.