Причины использования файлов свойств Ant вместо «Задач свойств»
В настоящее время я работаю с некоторыми разработчиками, которым нравится настраивать задачи Ant, которые определяют переменные среды, а не используют файлы свойств. Похоже, они предпочитают это делать, потому что набирать легче:
ant <environment task> dist
Затем набрать:
ant -propertyfile <environment property file> dist
Так например:
<project name = "whatever" default = "dist">
<target name = "local">
<property name = "webXml" value = "WebContent/WEB-INF/web-local.xml"/>
</target>
<target name = "remote">
<property name = "webXml" value = "WebContent/WEB-INF/web-remote.xml"/>
</target>
<target name = "build">
<!-- build tasks here --->
</target>
<target name = "dist" depends = "build">
<war destfile = "/dist/foo.war" webxml = "${webXml}">
<!-- rest of war tasks here -->
</war>
</target>
Мне трудно убедить их, что файлы свойств - это правильный путь. Я считаю, что файлы свойств лучше, потому что:
- Они обеспечивают большую гибкость - если вам нужна новая среда, просто добавьте новый файл свойств.
- Понятно, что происходит - вы должны знать об этой маленькой "уловке", чтобы понять, чего они добиваются.
- Не предоставляет значения по умолчанию и возможность использовать переопределения - если они использовали файлы свойств, они могли бы предоставить значения по умолчанию в верхней части проекта, но имеют возможность переопределить их с помощью файла
- Сценарий не сломается, если задача среды не указана в командной строке
Конечно, все, что они слышат, это то, что им нужно изменить свой сценарий Ant и ввести больше в командной строке.
Можете ли вы предоставить какие-либо дополнительные аргументы в пользу файлов свойств, а не «задач свойств»?
Ответы 3
Задачи свойств тесно связывают файл сборки со средой. Если ваши коллеги-разработчики утверждают, что они «должны изменить свой сценарий муравья» с вашими предложениями, почему они не спорят об изменении его каждый раз, когда им нужно развертывать в новой среде? :)
Возможно, вам удастся убедить их разрешить как конфигурацию файла свойств, так и конфигурацию командной строки. Я настроил свои сборки Ant так, что если build.properties существует в том же каталоге, что и build.xml, он считывает его. В противном случае он использует набор свойств по умолчанию, жестко закодированных в сборке. Это очень гибко.
<project name = "example">
<property file = "build.properties"/>
<property name = "foo.property" value = "foo"/>
<property name = "bar.property" value = "bar"/>
...
</project>
Я не предоставляю build.properties вместе с проектом (т.е. build.properties не имеет версии в SCM). Таким образом, разработчикам не нужно использовать файл свойств. Я предоставляю файл build.properties.example, на который разработчики могут ссылаться.
Начиная с Свойства Ant, однажды установленные, неизменяемы., файл сборки будет использовать свойства, определенные в следующем порядке:
- Свойства, предоставляемые с
-Dили-propertyfileчерез командную строку - Свойства, загруженные из build.properties
- Свойства по умолчанию в build.xml
Преимущества такого подхода:
- Файл сборки меньше и, следовательно, более удобен в обслуживании и менее подвержен ошибкам.
- Разработчики, которые просто не могут отказаться от настройки свойств в командной строке, по-прежнему могут их использовать.
- Файлы свойств можно использовать, но они не требуются
Аргументы, которые у вас есть, уже довольно убедительны. Если эти аргументы не сработали, споры не решат проблему. Фактически, ничего такого собирается решить проблему. Не думайте, что люди рациональны и будут делать самое практичное. Их эго вовлечено.
Перестать спорить. Даже если вы выиграете, создаваемые вами негодование и раздражение того не стоят. Выиграть в споре может быть хуже, чем проиграть.
Обоснуйте свой аргумент, а затем отпустите его. Возможно, через некоторое время они решат переключиться на ваш путь (потому что на самом деле так лучше). Если это произойдет, они будут действовать так, как будто это их собственная идея. Не будет упоминания о том, что вы это предложили.
С другой стороны, они могут никогда не переключиться.
Единственное решение - стремиться к авторитету, на котором вы можете говорить, как дела должны быть выполнены.
Проблема с первым решением (с использованием свойства ant) в основном заключается в жестком кодировании. Это может быть удобно, когда вы начинаете проект для себя, но вам нужно быстро избавиться от этой вредной привычки.
Я использую файл свойств, близкий к тому, что сказал robhruska, за исключением того, что я напрямую зафиксировал файл build.properties. Таким образом, у вас есть значение по умолчанию.
С другой стороны, я понимаю, что могу добавить эти значения по умолчанию в build.xml. (Я, вероятно, попробую это в следующие часы / дни ;-)).
В любом случае, мне очень не нравится первый подход, и я бы заставил этих ребят последовать второму ...