Причины использования файлов свойств Ant над «Задачами свойств» - PullRequest
Новая
       21

Причины использования файлов свойств Ant над «Задачами свойств»

4 голосов
/ 14 января 2009

В настоящее время я работаю с некоторыми разработчиками, которым нравится настраивать задачи 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 ]

15 голосов
/ 14 января 2009

Свойства задач тесно связывают файл сборки со средами. Если ваши коллеги-разработчики утверждают, что им «нужно изменить свой сценарий ant» с вашими предложениями, почему они не спорят об изменении его каждый раз, когда им приходится развертываться в новой среде? :)

Возможно, вы сможете убедить их разрешить как файл свойств, так и конфигурацию командной строки. Я настроил свои сборки 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

Преимущества этого подхода:

  • Файл сборки меньше и поэтому более удобен в обслуживании, менее подвержен ошибкам
  • Разработчики, которые просто не могут отойти от установки свойств в командной строке, могут по-прежнему использовать их.
  • Файлы свойств могут использоваться, но не обязательны
3 голосов
/ 14 января 2009

Аргументы, которые у вас есть, уже достаточно убедительны. Если эти аргументы не сработали, то спор не решит проблему. Фактически, ничто не решит проблему. Не думайте, что люди рациональны и будут делать самые практичные вещи. Их эго вовлечены.

Хватит спорить. Даже если вы выиграете, обида и раздражение, которые вы создадите, не будут стоить этого. Победа в споре может быть хуже, чем проигрыш.

Сделай свое дело, затем отпусти его. Возможно, что через некоторое время они решат перейти на ваш путь (потому что на самом деле это лучше). Если это произойдет, они будут действовать так, как будто это была их собственная идея. Там не будет упоминания о том, что вы предложили это.

С другой стороны, они могут никогда не переключаться.

Единственное решение - стремиться к власти, где вы можете сказать, как все должно быть сделано.

0 голосов
/ 14 января 2009

Проблема с первым решением (с использованием свойства ant) ​​в основном заключается в жестком кодировании. Это может быть удобно, когда вы начинаете проект для себя, но быстро вам нужно избавиться от этой вредной привычки.

Я использую файл свойств, близкий к тому, что сказал robhruska, за исключением того, что я зафиксировал файл build.properties напрямую. Таким образом, у вас есть по умолчанию.

С другой стороны, я понимаю, что могу добавить эти значения по умолчанию в build.xml. (Я, вероятно, попробую это в ближайшие часы / дни ;-)).

В любом случае, мне действительно не нравится первый подход, и я бы заставил этих парней последовать второму ...

...