Especificar el compilador de Eclipse completamente desde _within_ build.xml

Como experimento, queremos construir nuestros productos utilizando el compilador Eclipse java (ecj-3.5.jar descargado de eclipse.org) en la versión de tiempo de ejecución de Java 6 en lugar del JDK, y según tengo entendido, es cuestión de agregar este jar al ant classpath y configurando la propiedad build.compiler para que apunte al adaptador.

Incluyendo

<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter" />

en mi build.xml e invocando hormiga con un JRE, obtengo el error esperado de que no se puede encontrar el adaptador, y al agregar ecj-3.5.jar al classpath en el panel Eclipse puedo compilar mi código como se esperaba. Creo que la misma funcionalidad estará disponible con "-lib foo.jar" desde la línea de comandos con las hormigas modernas.

Ahora, quiero especificar dedentro&nbsp;build.xml que quiero ecj-3.5.jar en mi classpath que satisface lo mismo que arriba. Ya podemos hacer esto con las tareas de hormigas, así que creo que es posible.

Entonces la pregunta es: ¿Cómo puedo agregar al classpath utilizado por javac para localizar el compilador?solamente&nbsp;desde build.xml?

Parece que el próximo ant4eclipse 1.0 incluye el compilador Eclipse (que es para lo que quería usar esto), por lo que al actualizar a eso (desde 0.5) debería resolver el problema que tenemos.

24-09-2010: Ant4Eclipse todavía está en M4 sin indicación de cuándo ocurrirá el lanzamiento.

01/12/2011: ahora hemos migrado de hormiga a maven. Los scripts build.xml llegaron al muro de la complejidad y se necesitaba un nuevo enfoque. Cualquiera que necesite elegir qué hacer, no siga la ruta ant4eclipse, excepto para proyectos triviales.

2012-11-30: Un año después, la experiencia de Maven sigue siendo mayormente buena. Hay muchas peculiaridades y cambios en la mentalidad, pero la mayoría tiene sentido en el contexto. Maven puede especificar fácilmente el nivel del compilador en proyectos individuales. Estamos buscando usar ecj en lugar de javac (por varias razones) pero para la mayoría de los propósitos, javac funciona bien.