我目前正在与一些开发人员合作,他们喜欢设置定义环境特定变量的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脚本并且必须在命令行上输入更多内容。
您是否可以通过“属性任务”提供有利于属性文件的任何其他参数?
答案 0 :(得分:15)
属性任务将构建文件紧密耦合到环境。如果您的开发人员认为他们“必须根据您的建议改变他们的蚂蚁脚本”,他们为什么不在每次必须部署到新环境时都要改变它? :)
也许您可以说服他们同时允许属性文件和命令行配置。我设置了我的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属性(一旦设置)是不可变的,构建文件将使用按此顺序定义的属性:
-propertyfile
的属性
这种方法的优点:
答案 1 :(得分:3)
你的论据已经非常引人注目了。如果这些论点没有奏效,那么争论就不会解决问题。事实上, nothing 将解决问题。不要以为人是理性的,会做最实际的事情。他们的自负是参与其中的。
停止争论。即使你赢了,你创造的怨恨和烦恼也不值得。赢得争论可能比失败更糟糕。
说明问题,然后放手吧。有一段时间他们可能会决定改用你的方式(因为它实际上更好)。如果发生这种情况,他们会表现得像是他们自己的想法。没有提到你提出它。
另一方面,它们可能永远不会切换。
唯一的解决方案是努力争取一个权威的位置,在那里你可以说明如何完成任务。
答案 2 :(得分:0)
第一个解决方案(使用ant属性)的问题基本上是硬编码。 当你为自己开始一个项目时很方便,但很快你就必须消除这个坏习惯。
我正在使用一个属于robhruska的属性文件,除了我已经直接提交了build.properties文件。这样你就有了一个默认值。
另一方面,我知道我可以在build.xml中添加这些默认值。 (我可能会在接下来的几小时/天内尝试一下;-))。
无论如何,我真的不喜欢第一种方法,我会强迫那些人跟随第二种方法......