You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Marcus Lindblom <ma...@yar.nu> on 2006/09/08 13:53:58 UTC
Attempting to write a custom import-task
(I couldn't find anything in the mail-archives, nor on google, on this,
so I'm asking here. It's my first post to this list and I haven't
subscribed it previously either.)
Hi all,
Short version: How to use <import> from a <scriptdef> custom task?
Long version:
I'm trying to make a custom import task that performs some path-finding
& caching to locate other build-files, in a dependency-system that we've
developed on top of ant with the help of a set of beanshell-description.
(It allows various modules to refer to each others by name only, not via
paths. ). It works quite nice and Ant is really awesome, etc etc. :-)
Until now, we've used <import file="${ModuleName.ant.build}"/> to import
dependencies, which is run after importing our system-root-build.xml
which runs a script that sets all these properties. However, if that
module does not exists (not being checked out, misspelled, diretory
moved) there is no good way to report for an error or rather, to rescan
the directories for it (it should at least try that once per build.) So,
I thought of making my own import (call it mod-import) that takes a
'module' attribute and checks if the property is set, the build-file
exists, etc etc, before actually importing the file stored in the property.
But I run in to problem with calling ant's import, as it is set to only
be a top-level task, so calling project.create("import") from my
custom-import task fails. Is there any way around that, or are there
technical reasons for it to be so (rather than user-control issues)?
If my custom task could be defined to be a top-level task, which it is
and should be checked to be, then it should be able to access other
top-level tasks as well, no? (I don't know much about ant internals, so
I may be going in the wrong direction here.)
All help warmly welcomed.
Cheers,
/Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Attempting to write a custom import-task
Posted by Marcus Lindblom <ma...@yar.nu>.
I'm not using 1.7 (yet), but the latter seems easy enough. I was
thinking along those lines a bit but it was too simple. :)
Thanks!
/Marcus
Peter Reilly wrote:
> You have got to set the location and the target attributes of
> the import task, in ant 1.7 there is a utility method bindToTask
> to do this.
> <script language="beanshell">
> task = project.createTask("import");
> task.bindToOwner(self);
> task.setFile("import.me.xml");
> task.execute();
> </script>
>
> However, you are using beanshell, so an easier method would be
> to extend the import class itself:
>
> <script language="beanshell">
> import org.apache.tools.ant.taskdefs.ImportTask;
> public class MyImportTask extends ImportTask {
> private String me;
> public void setMe(String me) {
> this.me = me;
> }
> public void execute() {
> setFile(me);
> super.execute();
> }
> }
> project.addTaskDefinition("my.import", MyImportTask.class);
> </script>
>
> <my.import me="import.me.xml"/>
>
>
> Peter
>
> On 9/8/06, Marcus Lindblom <ma...@yar.nu> wrote:
>>
>> (I couldn't find anything in the mail-archives, nor on google, on this,
>> so I'm asking here. It's my first post to this list and I haven't
>> subscribed it previously either.)
>>
>> Hi all,
>>
>> Short version: How to use <import> from a <scriptdef> custom task?
>>
>> Long version:
>>
>> I'm trying to make a custom import task that performs some path-finding
>> & caching to locate other build-files, in a dependency-system that we've
>> developed on top of ant with the help of a set of beanshell-description.
>> (It allows various modules to refer to each others by name only, not via
>> paths. ). It works quite nice and Ant is really awesome, etc etc. :-)
>>
>> Until now, we've used <import file="${ModuleName.ant.build}"/> to import
>> dependencies, which is run after importing our system-root-build.xml
>> which runs a script that sets all these properties. However, if that
>> module does not exists (not being checked out, misspelled, diretory
>> moved) there is no good way to report for an error or rather, to rescan
>> the directories for it (it should at least try that once per build.) So,
>> I thought of making my own import (call it mod-import) that takes a
>> 'module' attribute and checks if the property is set, the build-file
>> exists, etc etc, before actually importing the file stored in the
>> property.
>>
>> But I run in to problem with calling ant's import, as it is set to only
>> be a top-level task, so calling project.create("import") from my
>> custom-import task fails. Is there any way around that, or are there
>> technical reasons for it to be so (rather than user-control issues)?
>>
>> If my custom task could be defined to be a top-level task, which it is
>> and should be checked to be, then it should be able to access other
>> top-level tasks as well, no? (I don't know much about ant internals, so
>> I may be going in the wrong direction here.)
>>
>> All help warmly welcomed.
>>
>> Cheers,
>> /Marcus
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Attempting to write a custom import-task
Posted by Peter Reilly <pe...@gmail.com>.
You have got to set the location and the target attributes of
the import task, in ant 1.7 there is a utility method bindToTask
to do this.
<script language="beanshell">
task = project.createTask("import");
task.bindToOwner(self);
task.setFile("import.me.xml");
task.execute();
</script>
However, you are using beanshell, so an easier method would be
to extend the import class itself:
<script language="beanshell">
import org.apache.tools.ant.taskdefs.ImportTask;
public class MyImportTask extends ImportTask {
private String me;
public void setMe(String me) {
this.me = me;
}
public void execute() {
setFile(me);
super.execute();
}
}
project.addTaskDefinition("my.import", MyImportTask.class);
</script>
<my.import me="import.me.xml"/>
Peter
On 9/8/06, Marcus Lindblom <ma...@yar.nu> wrote:
>
> (I couldn't find anything in the mail-archives, nor on google, on this,
> so I'm asking here. It's my first post to this list and I haven't
> subscribed it previously either.)
>
> Hi all,
>
> Short version: How to use <import> from a <scriptdef> custom task?
>
> Long version:
>
> I'm trying to make a custom import task that performs some path-finding
> & caching to locate other build-files, in a dependency-system that we've
> developed on top of ant with the help of a set of beanshell-description.
> (It allows various modules to refer to each others by name only, not via
> paths. ). It works quite nice and Ant is really awesome, etc etc. :-)
>
> Until now, we've used <import file="${ModuleName.ant.build}"/> to import
> dependencies, which is run after importing our system-root-build.xml
> which runs a script that sets all these properties. However, if that
> module does not exists (not being checked out, misspelled, diretory
> moved) there is no good way to report for an error or rather, to rescan
> the directories for it (it should at least try that once per build.) So,
> I thought of making my own import (call it mod-import) that takes a
> 'module' attribute and checks if the property is set, the build-file
> exists, etc etc, before actually importing the file stored in the
> property.
>
> But I run in to problem with calling ant's import, as it is set to only
> be a top-level task, so calling project.create("import") from my
> custom-import task fails. Is there any way around that, or are there
> technical reasons for it to be so (rather than user-control issues)?
>
> If my custom task could be defined to be a top-level task, which it is
> and should be checked to be, then it should be able to access other
> top-level tasks as well, no? (I don't know much about ant internals, so
> I may be going in the wrong direction here.)
>
> All help warmly welcomed.
>
> Cheers,
> /Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>