Diferencia entre revisiones de «Apache Ant»

De Wikipedia, la enciclopedia libre
Contenido eliminado Contenido añadido
m Revertidos los cambios de 189.195.3.98 (disc.) a la última edición de 88.26.179.166
Línea 83: Línea 83:
* [http://www.chuidiang.com/java/herramientas/ant.php Primeros pasos con Apache Ant] (español)
* [http://www.chuidiang.com/java/herramientas/ant.php Primeros pasos con Apache Ant] (español)
* [http://sherekan.com.ar/2009/06/21/introduccion-a-ant Tutorial completo sobre Ant] (español)
* [http://sherekan.com.ar/2009/06/21/introduccion-a-ant Tutorial completo sobre Ant] (español)
* [http://neossoftware.260mb.com/2009/06/primeros-pasos-usando-apache-ant/ Primeros pasos usando Apache ANT] (español)


[[Categoría:Herramientas de desarrollo para Java]]
[[Categoría:Herramientas de desarrollo para Java]]

Revisión del 14:51 23 jun 2009

Apache Ant
Información general
Autor Apache Software Foundation
Lanzamiento inicial julio de 2000
Licencia Licencia Apache
Información técnica
Programado en Java
Plataformas admitidas máquina virtual Java
Versiones
Última versión estable 1.7.1 ( 27 de junio de 2008)
Archivos legibles
Ant build file
Enlaces


Apache Ant es una herramienta usada en programación para la realización de tareas mecánicas y repetitivas, normalmente durante la fase de compilación y construcción (build). Es similar a Make pero sin las engorrosas dependencias del sistema operativo.

Esta herramienta, hecha en Java, tiene la ventaja de no depender de las órdenes de shell de cada sistema operativo, sino que se basa en archivos de configuración XML y clases Java para la realización de las distintas tareas, siendo idónea como solución multi-plataforma.

Ant es un proyecto de código abierto de la Apache Software Foundation.

Fichero de ejemplo build.xml

Debajo se muestra un archivo de ejemplo (build.xml) para una aplicación "Hola mundo" en Java. El archivo define tres objetivos - clean, compile y jar, cada uno de los cuales tiene una descripción asociada. El objetivo jar lista el objetivo compile como dependencia. Esto le dice a ANT que, antes de empezar el objetivo jar, debe completar el objetivo compile.

Dentro de cada objetivo están las acciones que debe tomar ANT para construir el objetivo. Por ejemplo, para construir el objetivo compile ANT debe primero crear un directorio llamado classes (ANT sólo lo hará si éste no existe previamente) y luego llamar al compilador de Java.

<?xml version="1.0"?>
<project name="Hello" default="compile">
    <target name="clean" description="borrar archivos temporales">
        <delete dir="classes" />
    </target>
    <target name="compile"
     description="compilar el código java a un archivo class">
        <mkdir dir="classes" />
        <javac srcdir="." destdir="classes" />
    </target>
    <target name="jar" depends="compile"
     description="crear un archivo Jar para la aplicación">
        <jar destfile="hello.jar">
            <fileset dir="classes" includes="**/*.class" />
            <manifest>
                <attribute name="Main-Class" value="HelloProgram" />
            </manifest>
        </jar>
    </target>
</project>

Portabilidad

Una de las primeras ayudas de Ant fue solucionar los problemas de portabilidad de Make. En un Makefile las acciones necesarias para crear un objetivo se especifican como órdenes de Intérprete de comandos que son específicos de la plataforma, normalmente un shell de Unix. Ant resuelve este problema proveyendo una gran cantidad de funcionalidades por él mismo, que pueden garantizar que permanecerán (casi) idénticas en todas las plataformas.

Por ejemplo, en el ejemplo build.xml debajo del objetivo clean borra el directorio classes y todo su contenido. En un Makefile esto normalmente se haría con la orden:

rm -rf classes/

rm es una orden específica de Unix que probablemente no estará disponible si el Makefile se usa en un entorno no Unix como Microsoft Windows. En un archivo de construcción Ant se puede conseguir lo mismo usando una orden propia:

<delete dir="classes" />

Una discrepancia común entre diferentes plataformas es la manera en que las rutas de directorios se especifican. Unix usa la barra (/) para delimitar los componentes de una ruta, mientras que Windows usa la barra invertida (\). Los archivos de Ant permiten al autor elegir su convención favorita, barras o barras invertidas para directorios, comas o punto y coma para separar rutas. Ant lo convierte todo al formato apropiado para la plataforma actual.

Historia

ANT fue creado por James Duncan Davidson mientras realizaba la transformación de un proyecto de Sun Microsystems en Open Source (concretamente la implementación de Servlets y JSP de Sun que luego se llamaría Jakarta Tomcat). En un entorno cerrado Make funcionaba correctamente bajo plataforma Solaris, pero para el entorno de open source, donde no era posible determinar la plataforma bajo la que se iba a compilar, era necesaria otra forma de trabajar. Así nació Ant como un simple intérprete que cogía un archivo XML para compilar Tomcat independientemente de la plataforma sobre la que operaba. A partir de este punto la herramienta fue adoptando nuevas funcionalidades y actualmente es un estándar en el mundo Java.

Limitaciones

  • Al ser una herramienta basada en XML, los archivos Ant deben ser escritos en XML. Esto es no sólo una barrera para los nuevos usuarios, sino también un problema en los proyectos muy grandes, cuando se construyen archivos muy grandes y complejos. Esto quizá sea un problema común a todos los lenguajes XML, pero la granularidad de las tareas de Ant (comparado con Maven, por decir alguno), significa que los problemas de escalabilidad llegan pronto.
  • La mayoría de las antiguas herramientas — las que se usan todos los días, como <javac>, <exec> y <java> — tienen malas configuraciones por defecto, valores para opciones que no son coherentes con las tareas más recientes. Ésta es la maldición de la compatibilidad hacia atrás: cambiar estos valores supone estropear las herramientas existentes.
  • Cuando se expanden las propiedades en una cadena o un elemento de texto, las propiedades no definidas no son planteadas como error, sino que se dejan como una referencia sin expandir (ej.: ${unassigned.property}). De nuevo, ésta es una cuestión de la compatibilidad hacia atrás, incluso se reconoce que tener la herramienta desactivada es normalmente la mejor opción, al menos hasta el punto que el mítico producto "Ant2.0" falle en propiedades no asignadas.
  • No es un lenguaje para un flujo de trabajo general, y no debería ser usado como tal. En particular, tiene reglas de manejo de errores limitadas, y no tiene persistencia de estado, así que no puede ser usado con confianza para manejar una construcción de varios días.

Enlaces externos