Re: A groovy frontend for Ant

[Stefan Bodewig]

On 2009-09-28, Nicolas Lalevée  wrote:

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

>> On 2009-09-27, Nicolas Lalevée  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 ( or a modified ) or for build files that specify a
basedir attribute holding an absolute path (most likely ${user.dir}).

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A groovy frontend for Ant

[Nicolas Lalevée]

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


On 2009-09-27, Nicolas Lalevée  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:passw...@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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A groovy frontend for Ant

[Stefan Bodewig]

On 2009-09-27, Nicolas Lalevée  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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A groovy frontend for Ant

[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  and  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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A groovy frontend for Ant

[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  and  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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A groovy frontend for Ant

[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  and  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

Re: A groovy frontend for Ant

[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
> 11180944m46bfa9ecs3eb8564a5e2d1...@mail.gmail.com%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  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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A groovy frontend for Ant

[Stefan Bodewig]

On 2009-08-31, Nicolas Lalevée  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


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  and friends
should eb able to chose one based on the format.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org