eclipse - tutorial - Script Ant para elegir entre versiones múltiples de classpaths

ant build

Question

Soy nuevo en los guiones Ant.

a continuación se describe el requisito

en mi espacio de trabajo, hay varios proyectos y tengo que hacer que mi proyecto trabaje en RAD y Eclipse IDE, así como en entornos Websphere, tomcat y jboss. He realizado ajustes específicos del proyecto para que el proyecto funcione en RAD y websphere y eclipse y tomcat n jboss ..

pero hay cambios en varios archivos como classpath n few config files.

esto me deja con tres versiones de espacio de trabajo.

pero mi idea es tener un espacio de trabajo con múltiples versiones de classpath, por ejemplo. classpath_eclipse, classpath_rad etc. y tienen un script ant que elegirá entre los archivos correctos durante la compilación, dependiendo de qué ide.

Así que chicos, por favor, sugieran algún enfoque sobre cómo puedo implementar este enfoque. totalmente nuevo para la hormiga .: /

Answer 1

Sugeriría usar Apache ivy para administrar classpaths complejos. Externa sus dependencias de compilación a un archivo ivy.xml por separado.

En segundo lugar, ivy puede descargar automáticamente tales dependencias, reduciendo el tamaño de su proyecto bajo el control de la fuente.

Finalmente, esta solución a primera vista puede parecer terriblemente compleja. Su ventaja es que es compatible con otras tecnologías de compilación como Maven .

Ejemplo

ivy.xml

Ivy usa "configuraciones" para administrar agrupaciones lógicas de jarras.

En este ejemplo, el código compila contra los archivos api de SLF4J, pero en el tiempo de ejecución utiliza diferentes implementaciones de registro:

<ivy-module version="2.0">
    <info organisation="com.myspotontheweb" module="demo"/>

    <configurations>
        <conf name="compile" description="Required to compile application"/>
        <conf name="runtime.simple"  description="Runtime environment with minimal logging" extends="compile"/>
        <conf name="runtime.complex" description="Runtime environment with logback enabled" extends="compile"/>
        <conf name="test"    description="Required for test only" extends="runtime.simple"/>
        <conf name="build"   description="ANT tasks used by build"/>
    </configurations>

    <dependencies>
        <!-- compile dependencies -->
        <dependency org="org.slf4j" name="slf4j-api" rev="1.6.4" conf="compile->default"/>

        <!-- simple runtime dependencies -->
        <dependency org="org.slf4j" name="slf4j-simple" rev="1.6.4" conf="runtime.simple->default"/>

        <!-- complex runtime dependencies -->
        <dependency org="ch.qos.logback" name="logback-classic" rev="1.0.3" conf="runtime.complex->default"/>

        <!-- test dependencies -->
        <dependency org="junit" name="junit" rev="4.10" conf="test->default"/>

        <!-- Build dependencies -->
        <dependency org="org.codehaus.groovy" name="groovy-all" rev="1.8.6" conf="build->default"/>
    </dependencies>

</ivy-module>

Notas:

• El atributo extends permite la creación de conjuntos de jar jar
• Por defecto, ivy se descargará de Maven Central (un repositorio abierto que ahora alberga aproximadamente el 90% del software de código abierto de Java).
• Al usar el atributo conf , puede asociar una dependencia con una o más de sus configuraciones definidas localmente.
• Ivy también se puede usar para administrar dependencias de tarea ANT de terceros

build.xml

Las tareas ANT de hiedra se importan como antlib . La tarea de caché de hiedra se utiliza para convertir una configuración administrada de hiedra en rutas de ANT normales y la tarea de informe de hiedra produce un informe de dependencia.

<project name="demo" default="build" xmlns:ivy="antlib:org.apache.ivy.ant">

    <target name="init">
        <ivy:resolve/>

        <ivy:report todir=''${ivy.reports.dir}'' graph=''false'' xml=''false''/>

        <ivy:cachepath pathid="compile.path" conf="compile"/>
        <ivy:cachepath pathid="runtime.simple.path" conf="runtime.simple"/>
        <ivy:cachepath pathid="runtime.complex.path" conf="runtime.complex"/>
        <ivy:cachepath pathid="test.path"    conf="test"/>
        <ivy:cachepath pathid="build.path"   conf="build"/>
    </target>
    ..
    ..

La tarea de recuperación de hiedra se utiliza para completar un directorio durante la fase de empaque de su aplicación:

<target name="war">
    <ivy:retrieve pattern="${build.dir}/libs/[artifact].[ext]" conf="runtime.complex"/>

    <war destfile="myapp.war" webxml="src/metadata/myapp.xml">
        <fileset dir="${src.dir}/html/myapp"/>
        <fileset dir="${src.dir}/jsp/myapp"/>
        <lib dir="${build.dir}/libs"/>
        <classes dir="${build.dir}/classes"/>
    </war>
</target>

Archivos de configuración IDE

Un plugin de Eclipse para hiedra está disponible.

• http://ant.apache.org/ivy/ivyde/

También es posible generar archivos de configuración IDE usando una tarea groovy incrustada. Lo siguiente es un ejemplo de Eclipse:

<target name="eclipse">
    <taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="build.path"/>

    <ivy:cachefileset setid="libfiles" conf="compile"/>

    <groovy>
    <arg value="${src.dir}"/>
    <arg value="${build.dir}/classes"/>

    import groovy.xml.MarkupBuilder

    //
    // Generate the project file
    //
    project.log("Creating .project")

    new File(".project").withWriter { writer ->
        def xml = new MarkupBuilder(writer)

        xml.projectDescription() {
            name(project.name)
            comment()
            projects()
            buildSpec() {
                buildCommand() {
                    name("org.eclipse.jdt.core.javabuilder")
                    arguments()
                }
            }
            natures() {
                nature("org.eclipse.jdt.core.javanature")
            }
        }
    }

    //
    // Generate the classpath file
    //
    // The "lib" classpathentry fields are populated using the ivy artifact report
    //
    project.log("Creating .classpath")

    new File(".classpath").withWriter { writer ->
        def xml = new MarkupBuilder(writer)

        xml.classpath() {
            classpathentry(kind:"src",    path:args[0])
            classpathentry(kind:"output", path:args[1])
            classpathentry(kind:"con",    path:"org.eclipse.jdt.launching.JRE_CONTAINER")

            project.references.libfiles.each {
                classpathentry(kind:"lib", path:it)
            }
        }
    }
    </groovy>        
</target>

Answer 2

Me gustaría compartir el enfoque que finalmente implementé.

Había classpath , settings y algunos project config xmls que dependían del tiempo de ejecución.

En cada proyecto, creamos una versión runtime_classpah & runtime_settings y configxml_runtime de cada archivo.

Se creó un target en ant que toma el runtime de runtime como parámetro, se aplica a cada proyecto y se copian los contenidos de classpath_runtime a classpath , setting_runtime to settings .

Y un objetivo que sobrescribe a configxml con contenido de configxml_runtime