incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Boudart <>
Subject EasyAnt and ProjectHelpers
Date Fri, 24 Aug 2012 22:28:35 GMT

I have made some expermentations with ProjectHelpers yesterday.

But first to understand why, i'll give you some points.

*Understanding ProjectHelpers*
Ant's core relies on ProjectHelpers to translate a buildFile (it can be
build.xml or more recently .groovy, or event .java files) into Ant Java
model. It should understand targets/ extensionPoints, and all other
elements (UnknownElements as they name it) are considered as typedef or
taskdefs. ProjectHelper implementation defines if they can parse buildFile
or antlib.xml.

*Our problems*
The default ProjectHelper is ProjectHelper2, it return all the time "true"
for both methods canParseBuildFile and canParseAntLib (this caused me some
troubles see below)

Some ant tasks invokes a static method
ProjectHelper.configureProject(Project project, File  buildFile). This is
for example the case of "Ant" task (the one designed to invoke target in
other buildFile).
But how could this work in easyant as our entry point is not a build.xml. I
guess our entry point is most of the time a module.ivy.
It means people can't use <ant> task or <antcall> (as it relies on <ant>
under the hood) if they want to invoke targets in other easyant projects.

This is not really problematic as easyant is responsible of invoking stuff
on submodules  based on project cross dependencies.

*Then where is the problem? *
I've started implementing a sonar plugin [1] using sonar ant task [2].
The plugin is pretty basic for instance and works only in mono project.
Then i wanted to make multimodule working. To invoke sonar they need to
collect informations across subprojects before running project analysis.
But how could we specify "subprojects" in "pure" ant ?
While reading the code of their ant task i realised that they were calling
ProjectHelper.configureProject(Project project, File buildFile).

This is probably not the easiest way for them to collect informations, i'm
in discussion with them to make something much more flexible (teasing....).

By the way this motivated me to experiment stuff with ProjectHelpers.
Since ant 1.8.2, you can have multiple project helpers. This was introduced
to support any combinaisons of import (build.xml importing .groovy ant file

I've commited a new projectHelper named ModuleIvyProjectHelper. It can
parse files ending with ".ivy" and cannot parse antlib. For the parsing
logic it uses EasyAntEngine under the hood.

I don't know if we should move code from EasyAntEngine to this
ProjectHelper, as this would probably create a circular dependency between
the two classes.

I don't know either if this ProjectHelper makes sense, that's why it isn't
registered in ProjectHelperRepository by default.

While implementing it i encountered a limitation on ProjectHelpers, if you
register ModuleIvyProjectHelper (with api or even with the task) it is not
taken into account.
Why ? because default ProjectHelper is the first declared in
ProjectHelperRepository and it always return true when canParseBuildFile
method is called.

To make our stuff work i've overriden the method canParseBuildFile in our
legacy ProjectHelper (the one that was supporting phases).


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message