EasyAnt and ProjectHelpers

[Jean-Louis Boudart <je...@gmail.com>]

Hi,

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....).

*Experimentations*
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
etc...).

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).

[1] https://github.com/easyant/sonar-plugin
[2] http://docs.codehaus.org/display/SONAR/Analyzing+with+Ant+Task

Re: EasyAnt and ProjectHelpers

[Jean-Louis Boudart <je...@gmail.com>]

Maybe this is a side effect of having our legacy project helper declared as
a Java 1.3 services :).

Know limitation: of ModuleIvyProjectHelper, you cannot give a
easyant-conf.xml. Maybe it would be a good idea to make easyant-conf.xml
handling more flexible (searching in
${user.home}/.easyant/easyant-conf.xml, and then in
${easyant.home}/easyant-conf.xml if no magic property is set).

Do you think having such ProjectHelper makes sense?

2012/8/25 Nicolas Lalevée <ni...@hibnet.org>

>
> Le 25 août 2012 à 00:28, Jean-Louis Boudart a écrit :
>
> > Hi,
> >
> > 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....).
> >
> > *Experimentations*
> > 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
> > etc...).
> >
> > 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.
>
> I think this is not true. In Ant there is an antunit test, and I have seen
> with the groovy and AntDSL experiments, we can dynamically register a
> project helper, and it is taken into account.
> I have re read the code of Ant, and by contruction, PorjectHelper2 is
> always the last to be tried. See
> org.apache.tools.ant.ProjectHelperRepository.ConstructingIterator
> If you have issues I guess it is somewhere else.
>
> Nicolas
>
>


-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/

Re: EasyAnt and ProjectHelpers

[Nicolas Lalevée <ni...@hibnet.org>]

Le 25 août 2012 à 00:28, Jean-Louis Boudart a écrit :

> Hi,
> 
> 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....).
> 
> *Experimentations*
> 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
> etc...).
> 
> 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.

I think this is not true. In Ant there is an antunit test, and I have seen with the groovy and AntDSL experiments, we can dynamically register a project helper, and it is taken into account.
I have re read the code of Ant, and by contruction, PorjectHelper2 is always the last to be tried. See
org.apache.tools.ant.ProjectHelperRepository.ConstructingIterator
If you have issues I guess it is somewhere else.

Nicolas