我目前正在与一些喜欢设置 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 脚本,并且必须在命令行上输入更多内容。
您能否提供任何支持属性文件而不是“属性任务”的额外参数?
最佳答案
属性任务将构建文件与环境紧密耦合。如果您的开发人员同事争辩说他们“必须根据您的建议更改他们的 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
通过命令行 这种方法的优点:
关于ant - 使用 Ant 属性文件超过 "Properties Tasks"的原因,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/444016/