A groovy frontend for Ant

[Nicolas Lalevée]

Some time ago I was starting to play with gant [1]. I found the groovy way of
writing build file more pleasant than the xml one. But I have found that the
gant implementation is not behaving exactly as ant does. Actually it is a
design choice, I would say that gant is a groovy soft that use ant tasks.

Then I read some time ago on this list that the Ant API could be used with
some other concrete syntaxes than the xml one. So I tried with groovy and I
think I was quite successful with the help of the actual implementation of
gant. Actually there are still some xml behind the hood [2]. But it doesn't
look so and the groovy language features are available everywhere in the file
(like if-then-else, for).

So it is a proof of concept, for some who are interested in, I checked it in
some other project of mine there:
https://lunercp.svn.sourceforge.net/svnroot/lunercp/trunk/org.hibnet.gant/

So the Ant API works perfectly well, I could nearly reused the ant packaging
without touching it (apart from putting the gant.jar in the classpath). The
only point that was not generic enougth is the default input file. It is
build.xml in ant and I wanted build.gant. I worked around it with a hack in
the gant.sh script.

Then I thought about patching ant so we could make it parametrable, usable by
other languages.

I thought about the ProjectHelper providing the proper default input file. But
as I looked into the sources of ant, it appears that the helper is created a
way too late for that purpose. Would it be reasonable to instanciate the
helper at the arguments parsing in the Main class (see Main#processArgs) ?
Another way I see to implement this is to make the Main class expose a
protected function getDefaultBuildFileName() which could be overrided in a
custom gant Main class.

Then there is also the problematic about the ant and subant tasks which are
expected a priori to launch ant with the pure xml frontend (I am right to see
it this way ?). But I think these tasks won't be able to so as they would use
the launching classpath which would be the groovy frontend one. So it would be
stated as unavailable and some gant and subgant tasks should be implemented
(with some smart overriding of the ant ones).

I have a preference for the first solution but I am not sure if ProjectHelper
is really meant to specify argument parsing behaviour.

Nicolas

[1] http://gant.codehaus.org/
[2] http://groovy.codehaus.org/GroovyMarkup

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On 2009-08-31, Nicolas Lalevée <nicolas.lalevee@...> wrote:

> So it is a proof of concept, for some who are interested in, I checked it in
> some other project of mine there:
> https://lunercp.svn.sourceforge.net/svnroot/lunercp/trunk/org.hibnet.gant/

Haven't looked at the code, yet, but you can as well use Ant's sandbox
for this, if you want to (just making sure, you know that you can, not
saying you should).

> The only point that was not generic enougth is the default input
> file. It is build.xml in ant and I wanted build.gant.

I recall that I was involved in similar discussions, it could have been
when I put together the JavaFront prototype here on the list or later in
some off-list discussion.  Ahh,  the thread starting here
<http://mail-archives.apache.org/mod_mbox/ant-dev/200811.mbox/%3C91dd9a4f0811180944m46bfa9ecs3eb8564a5e2d10c6@...%3E>

I know Jean-Louis BOUDART has been working on plugging different
frontends into EasyAnt so maybe we could join forces - Jean-Louis, are
you reading this?

> I thought about the ProjectHelper providing the proper default input file. But
> as I looked into the sources of ant, it appears that the helper is created a
> way too late for that purpose. Would it be reasonable to instanciate the
> helper at the arguments parsing in the Main class (see Main#processArgs) ?

I think it would, in particular if you consider the use case of maybe
supporting more than one ProjectHelper implementation in parallel (see
the old thread) like use groovy if it is a goovy build file and fall
back to ProjectHelper2 if it is xml.

> Then there is also the problematic about the ant and subant tasks which are
> expected a priori to launch ant with the pure xml frontend (I am right to see
> it this way ?).

I think the configured ProjectHelper is used, isn't it?  This probably
means we need support for multiple project helpers if <ant> and friends
should eb able to chose one based on the format.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nicolas Lalevée]

> > The only point that was not generic enougth is the default input
> > file. It is build.xml in ant and I wanted build.gant.
>
> I recall that I was involved in similar discussions, it could have been
> when I put together the JavaFront prototype here on the list or later in
> some off-list discussion.  Ahh,  the thread starting here
> <http://mail-archives.apache.org/mod_mbox/ant-dev/200811.mbox/%3C91dd9a4f08
>11180944m46bfa9ecs3eb8564a5e2d10c6@...%3E>

Cool, thanks for finding that thread.

>
> I know Jean-Louis BOUDART has been working on plugging different
> frontends into EasyAnt so maybe we could join forces - Jean-Louis, are
> you reading this?
>
> > I thought about the ProjectHelper providing the proper default input
> > file. But as I looked into the sources of ant, it appears that the helper
> > is created a way too late for that purpose. Would it be reasonable to
> > instanciate the helper at the arguments parsing in the Main class (see
> > Main#processArgs) ?
>
> I think it would, in particular if you consider the use case of maybe
> supporting more than one ProjectHelper implementation in parallel (see
> the old thread) like use groovy if it is a goovy build file and fall
> back to ProjectHelper2 if it is xml.
>
> > Then there is also the problematic about the ant and subant tasks which
> > are expected a priori to launch ant with the pure xml frontend (I am
> > right to see it this way ?).
>
> I think the configured ProjectHelper is used, isn't it?  This probably
> means we need support for multiple project helpers if <ant> and friends
> should eb able to chose one based on the format.

The suggestion made in the thread you undig from the archive is quite
interesting. There would be a default ProjectHelper which would define which
default input file ant should look for, and if a file is specified the
extension would designate the ProjectHelper to use. I looked into bugzilla, I
have not found any patch about this. Then I will look into coding an
implementation.

Nicolas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jean-Louis BOUDART]

Hi,
>
> >
> > I know Jean-Louis BOUDART has been working on plugging different
> > frontends into EasyAnt so maybe we could join forces - Jean-Louis, are
> > you reading this?
>

Sorry  for long responding i was on holidays :).
I was thinking a few time ago to introduce an abstraction layer in the
project helper.

As stefan highlighted <ant> and <subant> task are configured through the
ProjectHelper that's why i wanted to put the abstraction layer here.

Why adding a new abstraction layer ?
As everyone knows the only way to write an ant script is XML. It could be
really interesting to support others languages like Java or groovy.
Then if users want to write their own ant script they are able to write it
in XML (with ant syntax has everyone know in the world :)) or in Java (maybe
Groovy ? or whatever).

I thought about writing a ProjectHelper that will be in charge to determine
which "dialect" will be used (maybe based on conventions on extensions .ant
.java .jar .groovy) and to delegate to a class that will be in charge to do
all the specific stuff.

I didn't get time to start a POC on this but i will do it in the next few
days.

It could be cool if we could join forces on this.


Cheers
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org

[Nicolas Lalevée]

Le 11 sept. 09 à 18:46, Jean-Louis Boudart a écrit :

> Hi,
>>
>>>
>>> I know Jean-Louis BOUDART has been working on plugging different
>>> frontends into EasyAnt so maybe we could join forces - Jean-Louis,  
>>> are
>>> you reading this?
>>
>
> Sorry  for long responding i was on holidays :).
> I was thinking a few time ago to introduce an abstraction layer in the
> project helper.
>
> As stefan highlighted <ant> and <subant> task are configured through  
> the
> ProjectHelper that's why i wanted to put the abstraction layer here.
>
> Why adding a new abstraction layer ?
> As everyone knows the only way to write an ant script is XML. It  
> could be
> really interesting to support others languages like Java or groovy.
> Then if users want to write their own ant script they are able to  
> write it
> in XML (with ant syntax has everyone know in the world :)) or in  
> Java (maybe
> Groovy ? or whatever).
>
> I thought about writing a ProjectHelper that will be in charge to  
> determine
> which "dialect" will be used (maybe based on conventions on  
> extensions .ant
> .java .jar .groovy) and to delegate to a class that will be in  
> charge to do
> all the specific stuff.
>
> I didn't get time to start a POC on this but i will do it in the  
> next few
> days.
>
> It could be cool if we could join forces on this.

Here is a simple first patch:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47830

As noted there I still have some issues, probably in the groovy  
frontend.

Nicolas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nicolas Lalevée]

Le 13 sept. 09 à 16:44, Nicolas Lalevée a écrit :

>
> Le 11 sept. 09 à 18:46, Jean-Louis Boudart a écrit :
>
>> Hi,
>>>
>>>>
>>>> I know Jean-Louis BOUDART has been working on plugging different
>>>> frontends into EasyAnt so maybe we could join forces - Jean-
>>>> Louis, are
>>>> you reading this?
>>>
>>
>> Sorry  for long responding i was on holidays :).
>> I was thinking a few time ago to introduce an abstraction layer in  
>> the
>> project helper.
>>
>> As stefan highlighted <ant> and <subant> task are configured  
>> through the
>> ProjectHelper that's why i wanted to put the abstraction layer here.
>>
>> Why adding a new abstraction layer ?
>> As everyone knows the only way to write an ant script is XML. It  
>> could be
>> really interesting to support others languages like Java or groovy.
>> Then if users want to write their own ant script they are able to  
>> write it
>> in XML (with ant syntax has everyone know in the world :)) or in  
>> Java (maybe
>> Groovy ? or whatever).
>>
>> I thought about writing a ProjectHelper that will be in charge to  
>> determine
>> which "dialect" will be used (maybe based on conventions on  
>> extensions .ant
>> .java .jar .groovy) and to delegate to a class that will be in  
>> charge to do
>> all the specific stuff.
>>
>> I didn't get time to start a POC on this but i will do it in the  
>> next few
>> days.
>>
>> It could be cool if we could join forces on this.
>
> Here is a simple first patch:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47830
>
> As noted there I still have some issues, probably in the groovy  
> frontend.

So I have implemented a ProjectHelperRepository which will help Ant to  
choose a ProjectHelper to use (svn r819284). I have added some doc  
about it, see:
http://svn.apache.org/repos/asf/ant/core/trunk/docs/manual/projecthelper.html

So with this implementation, we would be able to just drop an  
implementation of ProjectHelper in a standard Ant distribution, and  
Ant will be able to parse new kinds of files, while still being able  
to build classical build.xml files.

Just one thing is worrying me: the ProjectHelper#parse method is  
expecting an Object as source, which as the javadoc specifies it can  
be a File, an URL, an InputStream, or even a specialized type as  
InputSource. Does it really used with something else than a File or an  
URL ? Should we continue to support that ? Shouldn't we better support  
only URL ? something that we can get content from and have a name.
And by the way shouldn't ProjectHelper be an abstract class ?

Nicolas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On 2009-09-27, Nicolas Lalevée <nicolas.lalevee@...> wrote:

> Just one thing is worrying me: the ProjectHelper#parse method is
> expecting an Object as source, which as the javadoc specifies it can
> be a File, an URL, an InputStream, or even a specialized type as
> InputSource. Does it really used with something else than a File or an
> URL ?

No, we don't do so, but it has been asked for a couple of times.  The
main thing holding back an implementation that was using URLs or streams
is "what should be use to resolve relative file names".

> Should we continue to support that ? Shouldn't we better support only
> URL ? something that we can get content from and have a name.

Imagine you want tp import a build file that's located in a database ...

> And by the way shouldn't ProjectHelper be an abstract class ?

Prior to Ant 1.6.0 ProjectHelper was the actual implemtation used by
Ant.  I think we kept it non-abstract in order to allow code that
directly instantiated ProjectHelper to compile.  I'm not sure whether
any such code ever existed and whether it is still relevant.  Would we
gain anything from making ProjectHelper abstract?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nicolas Lalevée]

Le 28 sept. 09 à 17:32, Stefan Bodewig a écrit :

> On 2009-09-27, Nicolas Lalevée <nicolas.lalevee@...> wrote:
>
>> Just one thing is worrying me: the ProjectHelper#parse method is
>> expecting an Object as source, which as the javadoc specifies it can
>> be a File, an URL, an InputStream, or even a specialized type as
>> InputSource. Does it really used with something else than a File or  
>> an
>> URL ?
>
> No, we don't do so, but it has been asked for a couple of times.  The
> main thing holding back an implementation that was using URLs or  
> streams
> is "what should be use to resolve relative file names".

I read again the javadoc about URL, and more specifically URI (added  
in java 1.4 so it would be OK now for Ant). There is a function to  
resolve a relative path: URI#resolve(URI). So everywhere Ant would  
manage URI until it has to get the content of the pointed file. It  
then resolves the URI relatively to the context (basedir for instance  
should be an URI too). As the URI is absolute it will get the URL:  
URI#toURL(). And finally get the content of that file, and in some  
case of referencing some build file, it would call  
ProjectHelper#parse(URL).

I didn't read the referenced RFC 2396 thought. I don't know what  
exactly does that resolve of relative URI.
And it may change Ant quite a bit too.
Just me thinking loud :)

>
>> Should we continue to support that ? Shouldn't we better support only
>> URL ? something that we can get content from and have a name.
>
> Imagine you want tp import a build file that's located in a  
> database ...

Then I would imagine that this file would be described as an URL like  
db://user:password@host:port/MyDb?select=.....
And there would some URLStreamHandler in the class path that can  
handle that kind of URL.

But then I wonder what relative path would mean in a such case...

>
>> And by the way shouldn't ProjectHelper be an abstract class ?
>
> Prior to Ant 1.6.0 ProjectHelper was the actual implemtation used by
> Ant.  I think we kept it non-abstract in order to allow code that
> directly instantiated ProjectHelper to compile.  I'm not sure whether
> any such code ever existed and whether it is still relevant.  Would we
> gain anything from making ProjectHelper abstract?

The only minor gain would be about making the parse method abstract,  
using the java language constructs rather than throwing a  
BuildException.
Let's keep API backward compatibility.


Nicolas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On 2009-09-28, Nicolas Lalevée <nicolas.lalevee@...> wrote:

> Le 28 sept. 09 à 17:32, Stefan Bodewig a écrit :

>> On 2009-09-27, Nicolas Lalevée <nicolas.lalevee@...> wrote:

>>> Just one thing is worrying me: the ProjectHelper#parse method is
>>> expecting an Object as source, which as the javadoc specifies it can
>>> be a File, an URL, an InputStream, or even a specialized type as
>>> InputSource. Does it really used with something else than a File or
>>> an
>>> URL ?

>> No, we don't do so, but it has been asked for a couple of times.  The
>> main thing holding back an implementation that was using URLs or
>> streams
>> is "what should be use to resolve relative file names".

> I read again the javadoc about URL, and more specifically URI (added
> in java 1.4 so it would be OK now for Ant). There is a function to
> resolve a relative path: URI#resolve(URI). So everywhere Ant would
> manage URI until it has to get the content of the pointed file.

Sure.  But the tasks usually expect a File argument.

Another idea is to allow anything other than a File (a Resource would
probably be the best choice anyway) only for tasks that specify a
basedir (<ant> or a modified <import>) or for build files that specify a
basedir attribute holding an absolute path (most likely ${user.dir}).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...