You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nicolas Lalevée <ni...@hibnet.org> on 2009/09/01 14:28:43 UTC
Re: A groovy frontend for Ant
> > 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@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 <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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: A groovy frontend for Ant
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-28, Nicolas Lalevée <ni...@hibnet.org> wrote:
> Le 28 sept. 09 à 17:32, Stefan Bodewig a écrit :
>> On 2009-09-27, Nicolas Lalevée <ni...@hibnet.org> 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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: A groovy frontend for Ant
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 28 sept. 09 à 17:32, Stefan Bodewig a écrit :
> On 2009-09-27, Nicolas Lalevée <ni...@hibnet.org> 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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: A groovy frontend for Ant
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-27, Nicolas Lalevée <ni...@hibnet.org> 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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: A groovy frontend for Ant
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: A groovy frontend for Ant
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: A groovy frontend for Ant
Posted by Jean-Louis Boudart <je...@gmail.com>.
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