1 - Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers. 2 - While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh. 3 - Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file. 4 - Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma. 5 - If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's. 6 - Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, that unless they explicitly ask for something else, they want help. 7 - Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional. 8 - Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where. 9 - Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know. 10 - Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry. 11 - build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run. 12 - Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves. 1 - Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers. 2 - While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh. 3 - Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file. 4 - Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma. 5 - If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's. 6 - Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, that unless they explicitly ask for something else, they want help. 7 - Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional. 8 - Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where. 9 - Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know. 10 - Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry. 11 - build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run. 12 - Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves. 谁能帮我翻译 我的分都给他 价值200分
可以下在appfuse,看看人家的build.xml是怎么写的
我在将项目从JBUILDER导入到ECLIPSE的过程中重新构建了一个Java web Project. 所以要写BUILDER.XML 这回明白了吧
http://ant.apache.org/manual/index.html
1 - Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers. 2 - While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh. 3 - Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file. 4 - Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma. 5 - If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's. 6 - Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, that unless they explicitly ask for something else, they want help. 7 - Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional. 8 - Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where. 9 - Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know. 10 - Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry. 11 - build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run. 12 - Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves.
1 - Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers. 2 - While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh. 3 - Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file. 4 - Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma. 5 - If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's. 6 - Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, that unless they explicitly ask for something else, they want help. 7 - Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional. 8 - Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where. 9 - Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know. 10 - Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry. 11 - build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run. 12 - Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves.
谁能帮我翻译
我的分都给他
价值200分
所以要写BUILDER.XML
这回明白了吧
<!-- Local system paths -->
<property name="servlet.jar" value="/javasoft/lib/jdbc2_0-stdext.jar"/>
<property name="jdbc20ext.jar" value="/javasoft/lib/servlet.jar"/>
<!-- NOTE: If "dist" target is used, a local
"projects/lib" directory will be utilized or created -->
<property name="distpath.project" value="/projects/lib"/>
<!-- Project settings -->
<property name="project.title" value="Jakarta Struts Blank "/>
<property name="project.distname" value="blank"/>
<property name="project.version" value="1.1"/>
<!-- Path settings -->
<property name="doc.path" value="./doc/api"/>
<property name="doc.src" value="./src/java"/>
<!-- classpath for Struts 1.1 -->
<path id="compile.classpath">
<pathelement path ="lib/commons-beanutils.jar"/>
<pathelement path ="lib/commons-digester.jar"/>
<pathelement path ="lib/struts.jar"/>
<pathelement path ="classes"/>
<pathelement path ="${classpath}"/>
</path>
<!-- Check timestamp on files -->
<target name="prepare">
<tstamp/>
</target>
<!-- Copy any resource or configuration files -->
<target name="resources">
<copy todir="classes" includeEmptyDirs="no">
<fileset dir="src/java">
<patternset>
<include name="**/*.conf"/>
<include name="**/*.properties"/>
<include name="**/*.xml"/>
</patternset>
</fileset>
</copy>
</target>
<!-- Normal build of application -->
<target name="compile" depends="prepare,resources">
<javac srcdir="src" destdir="classes">
<classpath refid="compile.classpath"/>
</javac>
</target>
<!-- Remove classes directory for clean build -->
<target name="clean"
description="Prepare for clean build">
<delete dir="classes"/>
<mkdir dir="classes"/>
</target>
<!-- Build Javadoc documentation -->
<target name="javadoc"
description="Generate JavaDoc API docs">
<delete dir="./doc/api"/>
<mkdir dir="./doc/api"/>
<javadoc sourcepath="./src/java"
destdir="./doc/api"
classpath="${servlet.jar}:${jdbc20ext.jar}"
packagenames="*"
author="true"
private="true"
version="true"
windowtitle="${project.title} API Documentation"
doctitle="<h1>${project.title} Documentation (Version ${project.version})</h1>"
bottom="Copyright © 2002">
<classpath refid="compile.classpath"/>
</javadoc>
</target>
<!-- Build entire project -->
<target name="project" depends="clean,prepare,compile,javadoc"/>
<!-- Create binary distribution -->
<target name="dist"
description="Create binary distribution"> <mkdir
dir="${distpath.project}"/>
<jar
jarfile="${distpath.project}/${project.distname}.jar"
basedir="./classes"/>
<copy
file="${distpath.project}/${project.distname}.jar"
todir="${distpath.project}"/> <war
basedir="../"
warfile="${distpath.project}/${project.distname}.war"
webxml="web.xml">
<exclude name="${distpath.project}/${project.distname}.war"/>
</war> </target>
<!-- Build project and create distribution-->
<target name="all" depends="project,dist"/></project>
我只是想编译一下 看看能否BUILD SUCCESSFUL
明白了吧
可以把我要改动的地方加上注释么
谢谢你了
我为你裸跪
<property name="conf.dir" value="${basedir}/conf" />
<property name="lib.dir" value="${basedir}/lib" />
<property name="web.dir" value="${basedir}/web" />
<property name="build.dir" value="${web.dir}/WEB-INF/classes" />
<property name="target.dir" value="${basedir}/target" />
<property name="test.dir" value="${basedir}/test" />
<property name="test.data" value="${target.dir}/test/data" />
<property name="test.build" value="${target.dir}/test/classes" />
<property name="functional_test.data" value="${target.dir}/test/fun_data" />
<property name="release.warfile" value="${target.dir}/war/${ant.project.name}.war" /> <taskdef resource="net/sf/antcontrib/antcontrib.properties" classpath="${lib.dir}/ant/ant-contrib.jar" /> <target name="usage">
<echo message="${ant.project.name} Build 文件" />
<echo message="------------------------------------------------------" />
<echo message="可选Target:" />
<echo message="" />
<echo message="compile --> 编译Java文件并复制资源文件" />
<echo message="war --> 生成项目war文件" />
<echo message="test --> 运行JUnit单元测试" />
<echo message="clean --> 清空项目" />
<input message="请选择一个Target" validargs="compile,war,test,clean" addproperty="ant.task" />
<antcall target="${ant.task}" />
</target> <!-- ===================================
初始化项目,建立目录并更新项目的依赖jar.
==================================== -->
<target name="init">
<mkdir dir="${build.dir}" />
<mkdir dir="${test.build}" />
<mkdir dir="${test.data}"/>
<mkdir dir="${functional_test.data}"/>
</target> <!-- ===================================
定义Class Path
==================================== -->
<path id="compile.classpath">
<fileset dir="${web.dir}/WEB-INF/lib" includes="*.jar" />
<fileset dir="lib" includes="**/*.jar" />
</path> <path id="test.classpath">
<path refid="compile.classpath" />
<path location="${build.dir}" />
</path>
<!-- 定义编译选项 -->
<property name="compiler.args" value="-encoding UTF-8" /> <patternset id="compiler.conf">
<exclude name="**/?*.java" />
</patternset> <!-- 检查环境 -->
<target name="check-env">
<!-- 检查JDK版本为5.0 -->
<fail message="Must Set the JAVA_HOME to JDK5.0">
<condition>
<not>
<equals arg1="${ant.java.version}" arg2="1.5" />
</not>
</condition>
</fail>
</target> <!-- ===================================
编译Java文件并复制资源文件
==================================== -->
<target name="compile" depends="check-env,init,i18n">
<if>
<available file="${src.dir}" />
<then>
<javac destdir="${build.dir}" debug="true">
<compilerarg line="${compiler.args}" />
<src path="${src.dir}" />
<classpath refid="compile.classpath" />
</javac>
</then>
</if> <copy_resource conf.dir="${src.dir}" build.dir="${build.dir}" />
<copy_resource conf.dir="${conf.dir}" build.dir="${build.dir}" /> <!-- 编译单元测试的Java文件 -->
<if>
<available file="${test.dir}" />
<then>
<javac destdir="${test.build}" debug="true">
<compilerarg line="${compiler.args}" />
<src path="${test.dir}" />
<classpath refid="test.classpath" />
</javac> </then>
</if> <copy_resource conf.dir="${test.dir}" build.dir="${test.build}" /> </target> <macrodef name="copy_resource">
<attribute name="build.dir" />
<attribute name="conf.dir" />
<sequential>
<!-- 复制resource下的资源文件到classes目录 -->
<if>
<available file="@{conf.dir}" />
<then>
<copy todir="@{build.dir}">
<fileset dir="@{conf.dir}">
<patternset refid="compiler.conf" />
<exclude name="**/.bak" />
</fileset>
</copy>
</then>
</if>
</sequential>
</macrodef> <!-- ===================================
中文i18N文件进行UTF-8转换
==================================== -->
<target name="i18n">
<if>
<available file="${conf.dir}/i18n/cn" />
<then>
<native2ascii src="${conf.dir}/i18n/cn" dest="${conf.dir}/i18n" encoding="UTF-8" />
</then>
</if>
</target> <!-- ===================================
生成war文件
==================================== -->
<target name="war" depends="compile">
<mkdir dir="${target.dir}/war/" /> <tstamp>
<format property="datestamp" pattern="yyyy-MM-dd" />
</tstamp>
<war destfile="${release.warfile}" webxml="${web.dir}/WEB-INF/web.xml" basedir="${web.dir}" excludes="**/web.xml">
<manifest>
<section name="Shared">
<attribute name="Date" value="${datestamp}" />
</section> <section name="Copyright">
<attribute name="Copy" value="(C) ${ant.project.name} 2007" />
</section>
</manifest>
</war>
</target> <!-- =========================================
运行JUnit测试
========================================= -->
<property name="test.report" value="${target.dir}/test/reports" /> <target name="test" depends="compile"> <!-- 检查 junit.jar -->
<available classname="junit.framework.TestCase" property="junit.present" />
<fail unless="junit.present" message="Please copy lib/junit-3.8.1.jar into env.ANT_HOME/lib or Class Path" />
<!-- 清除上次的data数据 -->
<delete dir="${test.data}" />
<mkdir dir="${test.data}" />
<!-- 执行测试 -->
<junit printsummary="yes" fork="true" errorProperty="test.failed" failureProperty="test.failed">
<classpath>
<path refid="test.classpath" />
<path location="${test.build}" />
</classpath>
<formatter type="xml" />
<formatter type="brief" usefile="false" /> <!-- 执行单个或批量的test case。
如果在命令行有定义testcase，
如: ant -Dtestcase=com.gresoft.sanitation.test.MyTestCase
则执行单个test case. -->
<test name="${testcase}" if="testcase" /> <batchtest todir="${test.data}">
<fileset dir="${test.build}">
<exclude name="**/functional/**/*Test.class" />
<include name="**/*Test.class" />
</fileset>
</batchtest>
</junit>
<if>
<istrue value="${test.failed}" />
<then>
<test-report report.dir="${test.report}" data.dir="${test.data}" />
<fail>Unit tests 失败. 请于${test.report}目录观看错误信息报表.</fail>
</then>
</if>
</target> <!-- 生成JUnit测试结果报表 -->
<macrodef name="test-report">
<attribute name="data.dir" />
<attribute name="report.dir" />
<sequential>
<mkdir dir="@{report.dir}" />
<junitreport todir="@{report.dir}">
<fileset dir="@{data.dir}">
<include name="TEST-*.xml" />
</fileset>
<report format="frames" todir="@{report.dir}" />
</junitreport>
</sequential>
</macrodef> <target name="test-all" depends="test,fun-test" /> <target name="deploy" depends="compile" description="Deploy application">
<copy todir="${deploy.path}/${ant.project.name}" preservelastmodified="true">
<fileset dir="${web.dir}">
<include name="**/*.*" />
</fileset>
</copy>
</target> <target name="deploywar" depends="war" description="Deploy application as a WAR file">
<copy todir="${deploy.path}" preservelastmodified="true">
<fileset dir="${target.dir}/war">
<include name="*.war" />
</fileset>
</copy>
</target> <!-- ===================================
清理项目,删除classes目录
==================================== -->
<target name="clean">
<delete dir="${build.dir}" />
<delete dir="${test.build}" />
</target></project>
这上也有100分
是这个地址
http://community.csdn.net/Expert/topic/5754/5754688.xml?temp=.2925379