What's wrong with <call> task?
<project>
<target name="foobar">
<echo message="Hello" />
<echo message="World" />
</target>
<target name="build">
<call target="foobar" />
</target>
</project>
Jarek
----- Original Message -----
From: "Mitch Denny" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 17, 2004 11:34 AM
Subject: [nant-dev] Idea: Inline task definitions (task
orchestration/macros).
> Hi folks,
>
> I had a chance to do some tinkering last night on a feature that I have
> desperately wanted in Nant for quite some time. The ability to do inline
> task definitions in XML that orchestrate a number of other tasks. It
> works like this:
>
> <project name="test">
> <taskdef name="foobar">
> <echo message="Hello" />
> <echo message="World" />
> </taskdef>
> <target name="build">
> <foobar />
> </target>
> </project>
>
> I've managed to get an implementation of this working by making a number
> of minor modifications to the source. The list of source files affected
> is:
>
> 1. Project.cs
> Added a loop to the InitializeProjectDocument method which reads the
> taskdef elements and creates a task builder for them. Also modified the
> loop that executes the global tasks so that it ignores the taskdef
> elements and doesn't treat them as tasks.
>
> 2. TaskBuilder.cs
> Added a new constructor which takes an XmlNode so the task builder can
> pass that onto the InlineTask instance when it is created. Also added a
> property IsInline as a flag to the task builder's CreateTask (modified)
> method to know to handle them in a special way.
>
> 3. InlineTask.cs
> This is a new class. This class takes the XmlNode that was stored with
> the TaskBuilder when the project file was read in. It's a TaskContainer
> so it just calls ExecuteChildTasks (modified).
>
> 4. TaskContainer.cs
> Added an overload for ExecuteChildTasks which allows the InlineTask
> class to override which XmlNode it users to parse over.
>
> I think that is pretty much it, although if I went through and did it
> again I'd be tempted to refactor things a little bit. Anyway, where I
> see this being useful is helping lower the barrier to entry for task
> developers by allowing them to just have .build files that they can
> include in without having to cut real code (and therefore have a build
> system for that code). I've tested that this works with include files
> and it does (so far).
>
> You might be wondering how this differs from target elements, and I
> think there is little difference to be honest, other than it feels more
> consistent when all you are doing is orchestrating the functionality of
> a number of tasks for reuse. It could also drive a few other tweaks such
> as the ability to have "private properties". On the taskdef element,
> somehow I'd like to be able to specify attributes which can be used just
> like properties for the tasks contained within the taskdef, but have
> their scope limited just for that run.
>
> I think there is enough to bite off there!
>
> ----------------------------------------
> - Mitch Denny
> - [EMAIL PROTECTED]
> - http://www.monash.net
> - +61 (414) 610141
> -
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
