在"属性任务"上使用Ant属性文件的原因

Question

我目前正在与一些开发人员合作,他们喜欢设置定义环境特定变量而不是使用属性文件的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脚本并且必须在命令行上输入更多内容.

你能提供任何额外的参数来支持属性文件而不是"属性任务"吗？

Answer 1

属性任务将构建文件紧密耦合到环境.如果您的开发人员认为他们"必须根据您的建议改变他们的蚂蚁脚本",他们为什么不在每次必须部署到新环境时都要改变它？:)

也许您可以说服他们同时允许属性文件和命令行配置.我设置了我的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中的默认属性

这种方法的优点:

• 构建文件更小,因此更易于维护,更不容易出错
• 在命令行中无法摆脱设置属性的开发人员仍然可以使用它们.
• 可以使用属性文件,但不是必需的