How do I intrepret this line in ant.xml and why put it in private.properties etc ?

[tangara goh]

Hi,

I came across many projects from github that are using ant to do build and deployment.  And I am totally lost.  I have watched youtube tutorial on how to use ant but still I am lost.

Could someone tells me what's the reason these info below are declared in private.properties ?  The author is using netbean and I am using Eclipse so is it necessary for me to use the below or is it ok that I deleted this file away? cos I am using external tomcat as a server.

deploy.ant.properties.file=C:\\Users\\MY-PC\\AppData\\Roaming\\NetBeans\\8.2\\tomcat80.properties
j2ee.server.domain=C:/Users/MY-PC/AppData/Roaming/NetBeans/8.2/apache-tomcat-8.0.27.0_base
j2ee.server.home=C:/Program Files/Apache Software Foundation/Apache Tomcat 8.0.27
j2ee.server.instance=tomcat80:home=C:\\Program Files\\Apache Software Foundation\\Apache Tomcat 8.0.27:base=apache-tomcat-8.0.27.0_base
selected.browser=Chrome.INTEGRATED
user.properties.file=C:\\Users\\MY-PC\\AppData\\Roaming\\NetBeans\\8.2\\build.properties

Also, I am totally lost how to intrepret the below infor....

My question is if I am going to use maven, can I delete the below, as I see that it doesn't contain any dependencies library...

<project default="-deploy-ant" basedir=".">
    <target name="-init" if="deploy.ant.enabled">
        <property file="${deploy.ant.properties.file}"/>
        <tempfile property="temp.module.folder" prefix="tomcat" destdir="${java.io.tmpdir}"/>
        <unwar src="${deploy.ant.archive}" dest="${temp.module.folder}">
            <patternset includes="META-INF/context.xml"/>
        </unwar>
        <xmlproperty file="${temp.module.folder}/META-INF/context.xml"/>
        <delete dir="${temp.module.folder}"/>
    </target>
    <target name="-check-credentials" if="deploy.ant.enabled" depends="-init">
        <fail message="Tomcat password has to be passed as tomcat.password property.">
            <condition>
                <not>
                    <isset property="tomcat.password"/>
                </not>
            </condition>
        </fail>
    </target>
    <target name="-deploy-ant" if="deploy.ant.enabled" depends="-init,-check-credentials">
        <echo message="Deploying ${deploy.ant.archive} to ${Context(path)}"/>
        <taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"
                 classpath="${tomcat.home}/server/lib/catalina-ant.jar"/>
        <deploy url="${tomcat.url}/manager" username="${tomcat.username}"
                password="${tomcat.password}" path="${Context(path)}"
                war="${deploy.ant.archive}"/>
        <property name="deploy.ant.client.url" value="${tomcat.url}${Context(path)}"/>
    </target>
    <target name="-undeploy-ant" if="deploy.ant.enabled" depends="-init,-check-credentials">
        <echo message="Undeploying ${Context(path)}"/>
        <taskdef name="undeploy"  classname="org.apache.catalina.ant.UndeployTask"
                classpath="${tomcat.home}/server/lib/catalina-ant.jar"/>
        <undeploy url="${tomcat.url}/manager" username="${tomcat.username}" 
                  password="${tomcat.password}" path="${Context(path)}"/>
    </target>

tks.

[Tim Holloway]

In answer to your first question, most of those properties appear to be to tell Ant where Netbeans is and where its copy of Tomcat is. Which is mostly useless except with Netbeans. Looks like maybe Netbeans was expected to launch a test browser as well, but I'm not sure.

In answer to your second question, those Ant actions are to deploy the WAR that has been built to the Tomcat server. Maven has a "deploy" goal instead, so you don't need any of that, although the information regarding the server location, application context, and other variable data would have to be translated into POM equivalents for the deploy goal to use.

As an editorial opinion, I've never been big on making Ant or Maven deploy my webapps. For development and testing I have Tomcat set to use the WAR as it was built (withing the source project) instead of exporting it to somewhere else. And for production, I build a stand-alone deployable that generally has to be handed over to the operations staff for security reasons. Or, if Jenkins is in control, I let Jenkins handle that part.