ant - 使用 Ant 属性文件超过 "Properties Tasks"的原因

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 脚本”，那么他们为什么不在每次必须部署到新环境时都进行更改呢？ :)

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

这种方法的优点:

构建文件更小，因此更易于维护，更不容易出错

无法摆脱在命令行设置属性的开发人员仍然可以使用它们。

可以使用属性文件，但不是必需的