Re: [nant-dev] SUBMISSION: Path Task
Sounds good to me. Thanks ! Ian Damir Simunic wrote: You'd probably want to call it then. Damir -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian MacLean Sent: Monday, December 15, 2003 4:06 AM To: Jaroslaw Kowalski Cc: Nant-Developers (E-Mail); William E Caputo Subject: Re: [nant-dev] SUBMISSION: Path Task or have scan for all nant objects - it might need renaming in that case. Maybe or somthing like that. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] SUBMISSION: Path Task
You'd probably want to call it then. Damir -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian MacLean Sent: Monday, December 15, 2003 4:06 AM To: Jaroslaw Kowalski Cc: Nant-Developers (E-Mail); William E Caputo Subject: Re: [nant-dev] SUBMISSION: Path Task or have scan for all nant objects - it might need renaming in that case. Maybe or somthing like that. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
On Mon, 15 Dec 2003, Ian MacLean <[EMAIL PROTECTED]> wrote:
> Path combine just does its best to create a resonable path string
> from the inouts you pass it.
Ah, I see.
sets foo to ${basedir}/bar in Ant. This would probably be the closest
thing then.
> I don't believe the available task currently does any searching
> either
Quite possible. In Ant it does ;-)
Stefan
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Not quite. Path combine just does its best to create a resonable path string from the inouts you pass it. It doesn't actually verify that the path exists or do any searching on the PATH. Having said that - a task or function would be a great addition to nant. I don't believe the available task currently does any searching either - it just does an exists test on the file path that you give it. Ian Stefan Bodewig wrote: On Sun, 14 Dec 2003, Gert Driesen <[EMAIL PROTECTED]> wrote: If we decide to add William's task, I think we should : [...] - split it up into at least 3 tasks, like Ant has : dirname, basename, and path-combine (or something, doesn't exist in Ant) Well, it would probably be called or something close (like Unix's which utility that says where on your PATH a given command exists). Ant already has in CVS HEAD and ISTR there also is/was a , but I don't remember where. Basically, the task in Ant would do the same as - i.e. look the file up in a given - but set the property to the file's location. Stefan --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
On Sun, 14 Dec 2003, Gert Driesen <[EMAIL PROTECTED]> wrote: > If we decide to add William's task, I think we should : [...] > - split it up into at least 3 tasks, like Ant has : dirname, > basename, and path-combine (or something, doesn't exist in Ant) Well, it would probably be called or something close (like Unix's which utility that says where on your PATH a given command exists). Ant already has in CVS HEAD and ISTR there also is/was a , but I don't remember where. Basically, the task in Ant would do the same as - i.e. look the file up in a given - but set the property to the file's location. Stefan --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
- Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Monday, December 15, 2003 4:10 AM Subject: Re: [nant-dev] SUBMISSION: Path Task > Yeah, > And now we have an excellent definition of what should be a task and > what should be a function - that we can add to the docs. Definitely, both this and the naming rules for properties/tasks/types should be added to the docs ... > One of us needs > to play devils advocate - quite often its been me :). It was a pleasure helping you out this time ;) Gert --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Yeah, And now we have an excellent definition of what should be a task and what should be a function - that we can add to the docs. One of us needs to play devils advocate - quite often its been me :). Ian Jaroslaw Kowalski wrote: PS. Sorry if I sometimes sound negative about expression support ... I really like and appreciate what you've done so far, but I just want to be sure we're doing the right thing and not let you guys get carried away in your enthousiasm too fast :-) But I agree that its really exciting stuff, and I hope to find time soon enough to dive in as well ... Actually your comments are very helpful. Keep them coming ;-) You convinced me and Ian that we should support properties with dashes and functions with the syntax: prefix::function-name-with-dashes(). Jarek --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Hmm - thats got me thinking. Currently we auto load 3 types of nant objects - Tasks, types and now functions. However there is only the one corresponding task - I'm wondering if we should either : add two extra tasks and or have scan for all nant objects - it might need renaming in that case. Maybe or somthing like that. I think I'd prefer to scan for all in the one task. in actual fact if you pass a directory to now it calls TypeFactory.scandir which will scan for all 3. However passing it an assembly path means it only calls TypeFactory.AddTasks. Ian Exactly. That's what Ian has implemented. Perhaps you'll be able to load functions on demand with something like task. I'm also thinking about supporting functions written in a
Re: [nant-dev] SUBMISSION: Path Task
Jarek: >See attached code for actual code used to implement path::* functions. That looks great, thanks! Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com idia ktesis, koine chresis --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Hi William! > Will functions be like tasks in that they can be written separately, > dropped in and just be available (e.g. by placing MyProjectFunctions.dll > in the nant bin)? Exactly. That's what Ian has implemented. Perhaps you'll be able to load functions on demand with something like task. I'm also thinking about supporting functions written in a
Re: [nant-dev] SUBMISSION: Path Task
> Also, depending on whether functional support is a) soon to be > incorporated, and b) modular and extensible, I would be willing to rewrite > the path task's functionality as functions (if they aren't already done). a) Yes, it's going to be incorporated in nant soon b) Yes, it's modular and extensible. Adding functions is ultra-easy (you just add one attribute). Check http://jaak.sav.net/nant-ee/nant-ee-test4.zip for a prebuilt nant binary that supports various functions, including path::*. Preliminary documentation is also included. You may want to check out "EE-patches" branch in CVS to get the source code. Functions are in "NAnt.Core.ExpressionEval.Functions" namespace. Jarek --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Ian: >Personally I think this case is fairly clear cut. Any >task that has a property attribute and whose purpose is to set that >attribute will be more simply expressed using a function: FWIW, I agree with this. I wrote the path task simply to make it unnecessary to have to use a script task over and over for a relatively common activity. However, I too think functions are a better way to accomplish this (I simply didn't realize that support for them was this far along). >That leads me to another point. "Functional" tasks like this tend to have >multiple "functions" combined in the one task to reduce the number >of tasks that need to be written. Yup, and that makes it hard to test them thoroughly because of the combinatorial explosion of parameter interactions. Having each operation as a single function that does a single thing makes the nant code (and thus the build script) more easily testable, and thus more robust (assuming each is actually tested). Which brings me to a related question: Will functions be like tasks in that they can be written separately, dropped in and just be available (e.g. by placing MyProjectFunctions.dll in the nant bin)? Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com idia ktesis, koine chresis --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Gert:
>I'm definitely not saying that we should provide a task alternative for
>every function we support in the expression eval, but by not providing
task
>support for "basic" build "tasks", we're actually forcing build authors
to
>use expression support ...
I look at the separation between tasks and functions like the difference
between a procedure and a function in a procedural programming language:
nant tasks are procedures that do something but don't return a value,
while nant functions are functions that don't do anything except return a
value based on their input.
With this distinction, we can see that sysinfo still makes sense as a
task. It doesn't return a value (its more like a procedure that
initializes a bunch of class variables. The path task in contrast, does
nothing except "return" a single value into a property, and so makes more
sense as a set of functions.
You can see the difference in these hypothetical method definitions:
void mkdir(string path) { /*unconditionally create a directory at the
given location*/
void sysinfo() { /*unconditionally set a clearly defined set of class
properties*/ }
string path(string partial, bool fullpath, bool pathonly) /*do ugly
branching and return a string*/ }
bool available(string resource, TypeEnum type) /*do ugly branching and
return a string*/ }
So, rather than forcing people one way or the other, I think functions
make it easier for nant users to see when each is appropriate to use (and
for submitters to write): Use functions to get single values, use tasks
for everything else.
>If we decide to add William's task, I think we should :
>(suggestions snipped)
>What do you think ?
I lean toward not incorporating my submission. I think functions are a
better approach for its functionality, and we don't lose anything for it
(indeed as Ian pointed out, it will actually be cleaner as a set of
functions).
Also, depending on whether functional support is a) soon to be
incorporated, and b) modular and extensible, I would be willing to rewrite
the path task's functionality as functions (if they aren't already done).
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
idia ktesis, koine chresis
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
> > PS. Sorry if I sometimes sound negative about expression support ... I > really like and appreciate what you've done so far, but I just want to be > sure we're doing the right thing and not let you guys get carried away in > your enthousiasm too fast :-) But I agree that its really exciting stuff, > and I hope to find time soon enough to dive in as well ... Actually your comments are very helpful. Keep them coming ;-) You convinced me and Ian that we should support properties with dashes and functions with the syntax: prefix::function-name-with-dashes(). Jarek --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
Guess we should have something similar to the Ant uptodate task (http://ant.apache.org/manual-1.6beta/CoreTasks/uptodate.html) ... would indeed be great if we could get rid of as well ... I always found the and tasks horrible constructs ... Gert PS. Sorry if I sometimes sound negative about expression support ... I really like and appreciate what you've done so far, but I just want to be sure we're doing the right thing and not let you guys get carried away in your enthousiasm too fast :-) But I agree that its really exciting stuff, and I hope to find time soon enough to dive in as well ... - Original Message - From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> To: "Ian MacLean" <[EMAIL PROTECTED]> Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 3:08 PM Subject: Re: [nant-dev] SUBMISSION: Path Task > Ok. Should we do something with uptodatefile before the merge? If we do so, > we can deprecate as well. > > Jarek > > - Original Message - > From: "Ian MacLean" <[EMAIL PROTECTED]> > To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> > Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" > <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" > <[EMAIL PROTECTED]> > Sent: Sunday, December 14, 2003 2:14 PM > Subject: Re: [nant-dev] SUBMISSION: Path Task > > > > Sounds good to me. > > > > Ian > > Jaroslaw Kowalski wrote: > > > > >Should I add Deprecated attribute to "propertyexists", "propertytrue" and > > >"taskexists" in EE-patches? > > > > > >Jarek > > >- Original Message - > > >From: "Ian MacLean" <[EMAIL PROTECTED]> > > >To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> > > >Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" > > ><[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" > > ><[EMAIL PROTECTED]> > > >Sent: Sunday, December 14, 2003 12:57 PM > > >Subject: Re: [nant-dev] SUBMISSION: Path Task > > > > > > > > > > > > > > >>+1 on the if task refactoring. I'm not sure about removing > > >>though. I realize that a getenv() function would provide equivalent > > >>functionality, however I like the fact that I just need to do > > >> > > >>and then I have access to the environment block without having to call > > >>any more functions. Maybe I have just a fondness for the current way of > > >>doing it. :) > > >> > > >>Ian > > >> > > >> > > >>Jaroslaw Kowalski wrote: > > >> > > >> > > >> > > >>>>Tasks should offer functionality on a much higher level than functions > > >>>> > > >>>> > > >... > > > > > > > > >>>> > > >>>> > > >>>Here's my dream about NAnt: > > >>> > > >>>1. Tasks should actually DO something. That "something" is: compile, > > >>> > > >>> > > >create, > > > > > > > > >>>delete, XSL transform, update from cvs, send email, run unit tests, > > >>> > > >>> > > >install, > > > > > > > > >>>uninstall, start/stop services, start/kill processes, > > >>> > > >>> > > >compress/decompress. > > > > > > > > >>>There'are actually some tasks that do nothing like that, but they > direct > > >>> > > >>> > > >the > > > > > > > > >>>build process: > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>
Re: [nant-dev] SUBMISSION: Path Task
Ok. Should we do something with uptodatefile before the merge? If we do so, we can deprecate as well. Jarek - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 2:14 PM Subject: Re: [nant-dev] SUBMISSION: Path Task > Sounds good to me. > > Ian > Jaroslaw Kowalski wrote: > > >Should I add Deprecated attribute to "propertyexists", "propertytrue" and > >"taskexists" in EE-patches? > > > >Jarek > >- Original Message - > >From: "Ian MacLean" <[EMAIL PROTECTED]> > >To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> > >Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" > ><[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" > ><[EMAIL PROTECTED]> > >Sent: Sunday, December 14, 2003 12:57 PM > >Subject: Re: [nant-dev] SUBMISSION: Path Task > > > > > > > > > >>+1 on the if task refactoring. I'm not sure about removing > >>though. I realize that a getenv() function would provide equivalent > >>functionality, however I like the fact that I just need to do > >> > >>and then I have access to the environment block without having to call > >>any more functions. Maybe I have just a fondness for the current way of > >>doing it. :) > >> > >>Ian > >> > >> > >>Jaroslaw Kowalski wrote: > >> > >> > >> > >>>>Tasks should offer functionality on a much higher level than functions > >>>> > >>>> > >... > > > > > >>>> > >>>> > >>>Here's my dream about NAnt: > >>> > >>>1. Tasks should actually DO something. That "something" is: compile, > >>> > >>> > >create, > > > > > >>>delete, XSL transform, update from cvs, send email, run unit tests, > >>> > >>> > >install, > > > > > >>>uninstall, start/stop services, start/kill processes, > >>> > >>> > >compress/decompress. > > > > > >>>There'are actually some tasks that do nothing like that, but they direct > >>> > >>> > >the > > > > > >>>build process: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>
Re: [nant-dev] SUBMISSION: Path Task
Sounds good to me. Ian Jaroslaw Kowalski wrote: Should I add Deprecated attribute to "propertyexists", "propertytrue" and "taskexists" in EE-patches? Jarek - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 12:57 PM Subject: Re: [nant-dev] SUBMISSION: Path Task +1 on the if task refactoring. I'm not sure about removing though. I realize that a getenv() function would provide equivalent functionality, however I like the fact that I just need to do and then I have access to the environment block without having to call any more functions. Maybe I have just a fondness for the current way of doing it. :) Ian Jaroslaw Kowalski wrote: Tasks should offer functionality on a much higher level than functions ... Here's my dream about NAnt: 1. Tasks should actually DO something. That "something" is: compile, create, delete, XSL transform, update from cvs, send email, run unit tests, install, uninstall, start/stop services, start/kill processes, compress/decompress. There'are actually some tasks that do nothing like that, but they direct the build process:
Re: [nant-dev] SUBMISSION: Path Task
Should I add Deprecated attribute to "propertyexists", "propertytrue" and "taskexists" in EE-patches? Jarek - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> Cc: "Gert Driesen" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]>; "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 12:57 PM Subject: Re: [nant-dev] SUBMISSION: Path Task > +1 on the if task refactoring. I'm not sure about removing > though. I realize that a getenv() function would provide equivalent > functionality, however I like the fact that I just need to do > > and then I have access to the environment block without having to call > any more functions. Maybe I have just a fondness for the current way of > doing it. :) > > Ian > > > Jaroslaw Kowalski wrote: > > >>Tasks should offer functionality on a much higher level than functions ... > >> > >> > > > >Here's my dream about NAnt: > > > >1. Tasks should actually DO something. That "something" is: compile, create, > >delete, XSL transform, update from cvs, send email, run unit tests, install, > >uninstall, start/stop services, start/kill processes, compress/decompress. > > > >There'are actually some tasks that do nothing like that, but they direct the > >build process: > > > > > > > > > > > > > > > > > > > > > >
Re: [nant-dev] SUBMISSION: Path Task
+1 on the if task refactoring. I'm not sure about removing though. I realize that a getenv() function would provide equivalent functionality, however I like the fact that I just need to do and then I have access to the environment block without having to call any more functions. Maybe I have just a fondness for the current way of doing it. :) Ian Jaroslaw Kowalski wrote: Tasks should offer functionality on a much higher level than functions ... Here's my dream about NAnt: 1. Tasks should actually DO something. That "something" is: compile, create, delete, XSL transform, update from cvs, send email, run unit tests, install, uninstall, start/stop services, start/kill processes, compress/decompress. There'are actually some tasks that do nothing like that, but they direct the build process:
Re: [nant-dev] SUBMISSION: Path Task
> Tasks should offer functionality on a much higher level than functions ... Here's my dream about NAnt: 1. Tasks should actually DO something. That "something" is: compile, create, delete, XSL transform, update from cvs, send email, run unit tests, install, uninstall, start/stop services, start/kill processes, compress/decompress. There'are actually some tasks that do nothing like that, but they direct the build process:
Re: [nant-dev] SUBMISSION: Path Task
I think that fear is unfounded Gert. Tasks and elements are great for declarative constructs like filesets but no so good for functional things like looking up a value and are actually quite cumbersome for those sorts of things. xslt has had functions from the start and I'm never tempted to try to implement a match template as a function - its probably possible but it would be a major PITA. Ian Gert Driesen wrote: Jarek, I know this can all be implemented using functions, but my concern is that build files might start looking like regular source code instead of xml files, that's all ... Function support is something NAnt urgently needed, and I will definitely use it myself, but I just want to make sure we don't (ab)use it for just about everything, and don't offer users any alternatives ... Tasks should offer functionality on a much higher level than functions ... Gert - Original Message - From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 11:48 AM Subject: Re: [nant-dev] SUBMISSION: Path Task We already have tasks: that are basically readonly (they only change properties) and are just used to retrieve/calculate some information. We have four ways of doing so, why add fifth one? I think this should be done as a function ONLY: It's both readable and can be used in all places, like CSC task: ... or: ... Try it: http://jaak.sav.net/nant-ee/nant-ee-test4.zip Jarek - Original Message - From: "Gert Driesen" <[EMAIL PROTECTED]> To: "Ian MacLean" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 11:21 AM Subject: Re: [nant-dev] SUBMISSION: Path Task Guess this will be the start of many dilemma's ... I'm pretty sure there will always be people that prefer xml build elements only, and actually that's also one of my concerns ... I'd hate to see build files reduced to large chunks of scripts ... As long as we allow build authors to choose themselves I certainly have no problem with the expression eval support, I actually like it very much, but we should give build authors a choice in this matter ... I'm definitely not saying that we should provide a task alternative for every function we support in the expression eval, but by not providing task support for "basic" build "tasks", we're actually forcing build authors to use expression support ... If we decide to add William's task, I think we should : - add it to NAntContrib first - split it up into at least 3 tasks, like Ant has : dirname, basename, and path-combine (or something, doesn't exist in Ant) What do you think ? Gert - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "William E Caputo" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 5:38 AM Subject: Re: [nant-dev] SUBMISSION: Path Task This looks good William. However I'm thinking that the new function support will be easier to use to do this kind of stuff. the following path related functions will be included: path.changeextension path.combine path.getdirectoryname path.getextension path.getfilename path.getfilenamewithoutextension path.getfullpath path.getpathroot path.gettempfilename path.gettemppath path.hasextension path.ispathrooted Ian William E Caputo wrote: (This is a resend. I didn't see it come across the list the first time I sent it. My apologies if it comes through twice) Hi All, Attached is a zip file containing a task called path. This task extracts path information from a given partial (or complete) path name and optionally expands it to a fully-qualified path, using either the current working directory or the Project's base directory as the root, and places in a designated property. I looked through the list of tasks and didn't see anything that did something like this (and we needed it) so after implementing it in a script task, I decided to code it up as a full-fledged task and submit it in the hope that it will be useful to others. I wrote it is as being in the Nant.Core namespace because that is where copy and mkdir are (and we seem to always be manipulating paths in our build files) but if the project's admins prefer that it be a somewhere else in NAnt or submitted to NAntCont
Re: [nant-dev] SUBMISSION: Path Task
Ahh ok, rant away. Personally I think this case is fairly clear cut. Any
task that has a property attribute and whose purpose is to set that
attribute will be more simply expressed using a function:
so
vs
or
That leads me to another point. "Functional" tasks like this tend to have multiple "functions" combined in the one task to reduce the number of tasks that need to be written.
- hence your suggestion to split the path task it into 3 . The available task is the same - it really has 4 "functions" |File| |Directory|, |Framework| or |FrameworkSDK|. As a result these types of tasks have
a tendancy to become unweildy as more attributes are added to encompass more functionality. Functions have the added advantage of composability ie
file.exists( path.getfullpath("foo\bar\file.txt") ). To do the same without functions would require the use of 2 tasks and the use of an intermediate property.
the regex task, availabletask and registry reading tasks fall into a
similar category. For those tasks we can keep them around in parallell
with the new functions and then we can take a user poll further down the
road and see what peoples preferences are. I don't have a problem with
keeping certain things as tasks as well as there corresponding
functions- as long as the implementation is shared with the function
version.
I don't think that anyone is suggesting the wholesale replacement of
tasks with functions and in most cases you couldn't and shouldn't
replace a task with an equivalent function.
Of course there will be cases where its not clear whether a given piece
of functionality should be a task or a function. I don't believe that
this is one of them - feel free to disagree with me.
Ian
Gert Driesen wrote:
Guess this will be the start of many dilemma's ... I'm pretty sure there
will always be people that prefer xml build elements only, and actually
that's also one of my concerns ... I'd hate to see build files reduced to
large chunks of scripts ...
As long as we allow build authors to choose themselves I certainly have no
problem with the expression eval support, I actually like it very much, but
we should give build authors a choice in this matter ...
I'm definitely not saying that we should provide a task alternative for
every function we support in the expression eval, but by not providing task
support for "basic" build "tasks", we're actually forcing build authors to
use expression support ...
If we decide to add William's task, I think we should :
- add it to NAntContrib first
- split it up into at least 3 tasks, like Ant has : dirname, basename,
and path-combine (or something, doesn't exist in Ant)
What do you think ?
Gert
- Original Message -
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "William E Caputo" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, December 14, 2003 5:38 AM
Subject: Re: [nant-dev] SUBMISSION: Path Task
This looks good William. However I'm thinking that the new function
support will be easier to use to do this kind of stuff.
the following path related functions will be included:
path.changeextension
path.combine
path.getdirectoryname
path.getextension
path.getfilename
path.getfilenamewithoutextension
path.getfullpath
path.getpathroot
path.gettempfilename
path.gettemppath
path.hasextension
path.ispathrooted
Ian
William E Caputo wrote:
(This is a resend. I didn't see it come across the list the first time I
sent it. My apologies if it comes through twice)
Hi All,
Attached is a zip file containing a task called path. This task extracts
path information from a given partial (or complete) path name and
optionally expands it to a fully-qualified path, using either the current
working directory or the Project's base directory as the root, and places
in a designated property.
I looked through the list of tasks and didn't see anything that did
something like this (and we needed it) so after implementing it in a
script task, I decided to code it up as a full-fledged task and submit it
in the hope that it will be useful to others.
I wrote it is as being in the Nant.Core namespace because that is where
copy and mkdir are (and we seem to always be manipulating paths in our
build files) but if the project's admins prefer that it be a somewhere
else in NAnt or submitted to NAntContrib instead that is fine by me (I
didn't cross post, but I will send it to that list if you like).
The task is accompanied by 12 tests, and is fully documented.
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
idia ktesis, koine chresis
Hi All,
Attached is a zip file containing a task called path. This task extracts
path information from a given partial (or complete) path name and
optionally expands it to a fully-qualified path,
Re: [nant-dev] SUBMISSION: Path Task
Jarek,
I know this can all be implemented using functions, but my concern is that
build files might start looking like regular source code instead of xml
files, that's all ...
Function support is something NAnt urgently needed, and I will definitely
use it myself, but I just want to make sure we don't (ab)use it for just
about everything, and don't offer users any alternatives ...
Tasks should offer functionality on a much higher level than functions ...
Gert
- Original Message -
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean"
<[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
Sent: Sunday, December 14, 2003 11:48 AM
Subject: Re: [nant-dev] SUBMISSION: Path Task
>
> We already have tasks:
>
>
>
>
>
>
> that are basically readonly (they only change properties) and are just
used
> to retrieve/calculate some information. We have four ways of doing so, why
> add fifth one? I think this should be done as a function ONLY:
>
>
> value="${path::get-file-name-without-extension(somepath)}" />
>
> It's both readable and can be used in all places, like CSC task:
>
>
> ...
>
>
> or:
>
>
> ...
>
>
> Try it:
>
> http://jaak.sav.net/nant-ee/nant-ee-test4.zip
>
> Jarek
>
> - Original Message -
> From: "Gert Driesen" <[EMAIL PROTECTED]>
> To: "Ian MacLean" <[EMAIL PROTECTED]>; "William E Caputo"
> <[EMAIL PROTECTED]>
> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
> Sent: Sunday, December 14, 2003 11:21 AM
> Subject: Re: [nant-dev] SUBMISSION: Path Task
>
>
> >
> >
> > Guess this will be the start of many dilemma's ... I'm pretty sure there
> > will always be people that prefer xml build elements only, and actually
> > that's also one of my concerns ... I'd hate to see build files reduced
to
> > large chunks of scripts ...
> >
> > As long as we allow build authors to choose themselves I certainly have
no
> > problem with the expression eval support, I actually like it very much,
> but
> > we should give build authors a choice in this matter ...
> >
> > I'm definitely not saying that we should provide a task alternative for
> > every function we support in the expression eval, but by not providing
> task
> > support for "basic" build "tasks", we're actually forcing build authors
to
> > use expression support ...
> >
> >
> >
> > If we decide to add William's task, I think we should :
> > - add it to NAntContrib first
> > - split it up into at least 3 tasks, like Ant has : dirname,
basename,
> > and path-combine (or something, doesn't exist in Ant)
> >
> > What do you think ?
> >
> > Gert
> >
> > - Original Message -
> > From: "Ian MacLean" <[EMAIL PROTECTED]>
> > To: "William E Caputo" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Sunday, December 14, 2003 5:38 AM
> > Subject: Re: [nant-dev] SUBMISSION: Path Task
> >
> >
> > > This looks good William. However I'm thinking that the new function
> > > support will be easier to use to do this kind of stuff.
> > >
> > > the following path related functions will be included:
> > >
> > > path.changeextension
> > > path.combine
> > > path.getdirectoryname
> > > path.getextension
> > > path.getfilename
> > > path.getfilenamewithoutextension
> > > path.getfullpath
> > > path.getpathroot
> > > path.gettempfilename
> > > path.gettemppath
> > > path.hasextension
> > > path.ispathrooted
> > >
> > > Ian
> > >
> > > William E Caputo wrote:
> > >
> > > >(This is a resend. I didn't see it come across the list the first
time
> I
> > > >sent it. My apologies if it comes through twice)
> > > >
> > > >Hi All,
> > > >
> > > >Attached is a zip file containing a task called path. This task
> extracts
> > > >path information from a given partial (or complete) path name and
> > > >optionally expands it to a fully-qualified path, using either the
> current
> > > >working directory or the Project's base directory as the root, and
> places
> > > >in a designated property.
&g
Re: [nant-dev] SUBMISSION: Path Task
We already have tasks: that are basically readonly (they only change properties) and are just used to retrieve/calculate some information. We have four ways of doing so, why add fifth one? I think this should be done as a function ONLY: It's both readable and can be used in all places, like CSC task: ... or: ... Try it: http://jaak.sav.net/nant-ee/nant-ee-test4.zip Jarek - Original Message - From: "Gert Driesen" <[EMAIL PROTECTED]> To: "Ian MacLean" <[EMAIL PROTECTED]>; "William E Caputo" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 11:21 AM Subject: Re: [nant-dev] SUBMISSION: Path Task > > > Guess this will be the start of many dilemma's ... I'm pretty sure there > will always be people that prefer xml build elements only, and actually > that's also one of my concerns ... I'd hate to see build files reduced to > large chunks of scripts ... > > As long as we allow build authors to choose themselves I certainly have no > problem with the expression eval support, I actually like it very much, but > we should give build authors a choice in this matter ... > > I'm definitely not saying that we should provide a task alternative for > every function we support in the expression eval, but by not providing task > support for "basic" build "tasks", we're actually forcing build authors to > use expression support ... > > > > If we decide to add William's task, I think we should : > - add it to NAntContrib first > - split it up into at least 3 tasks, like Ant has : dirname, basename, > and path-combine (or something, doesn't exist in Ant) > > What do you think ? > > Gert > > - Original Message - > From: "Ian MacLean" <[EMAIL PROTECTED]> > To: "William E Caputo" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, December 14, 2003 5:38 AM > Subject: Re: [nant-dev] SUBMISSION: Path Task > > > > This looks good William. However I'm thinking that the new function > > support will be easier to use to do this kind of stuff. > > > > the following path related functions will be included: > > > > path.changeextension > > path.combine > > path.getdirectoryname > > path.getextension > > path.getfilename > > path.getfilenamewithoutextension > > path.getfullpath > > path.getpathroot > > path.gettempfilename > > path.gettemppath > > path.hasextension > > path.ispathrooted > > > > Ian > > > > William E Caputo wrote: > > > > >(This is a resend. I didn't see it come across the list the first time I > > >sent it. My apologies if it comes through twice) > > > > > >Hi All, > > > > > >Attached is a zip file containing a task called path. This task extracts > > >path information from a given partial (or complete) path name and > > >optionally expands it to a fully-qualified path, using either the current > > >working directory or the Project's base directory as the root, and places > > >in a designated property. > > > > > >I looked through the list of tasks and didn't see anything that did > > >something like this (and we needed it) so after implementing it in a > > >script task, I decided to code it up as a full-fledged task and submit it > > >in the hope that it will be useful to others. > > > > > >I wrote it is as being in the Nant.Core namespace because that is where > > >copy and mkdir are (and we seem to always be manipulating paths in our > > >build files) but if the project's admins prefer that it be a somewhere > > >else in NAnt or submitted to NAntContrib instead that is fine by me (I > > >didn't cross post, but I will send it to that list if you like). > > > > > >The task is accompanied by 12 tests, and is fully documented. > > > > > >Best, > > >Bill > > > > > >William E. Caputo > > >ThoughtWorks, Inc. > > >http://www.williamcaputo.com > > > > > >idia ktesis, koine chresis > > > > > >Hi All, > > > > > >Attached is a zip file containing a task called path. This task extracts > > >path information from a given partial (or complete) path name and > > >optionally expands it to a fully-qualified path, using either the current > > >working directory or the Project's base directory as the root, and places > > >in a design
Re: [nant-dev] SUBMISSION: Path Task
Guess this will be the start of many dilemma's ... I'm pretty sure there will always be people that prefer xml build elements only, and actually that's also one of my concerns ... I'd hate to see build files reduced to large chunks of scripts ... As long as we allow build authors to choose themselves I certainly have no problem with the expression eval support, I actually like it very much, but we should give build authors a choice in this matter ... I'm definitely not saying that we should provide a task alternative for every function we support in the expression eval, but by not providing task support for "basic" build "tasks", we're actually forcing build authors to use expression support ... If we decide to add William's task, I think we should : - add it to NAntContrib first - split it up into at least 3 tasks, like Ant has : dirname, basename, and path-combine (or something, doesn't exist in Ant) What do you think ? Gert - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "William E Caputo" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, December 14, 2003 5:38 AM Subject: Re: [nant-dev] SUBMISSION: Path Task > This looks good William. However I'm thinking that the new function > support will be easier to use to do this kind of stuff. > > the following path related functions will be included: > > path.changeextension > path.combine > path.getdirectoryname > path.getextension > path.getfilename > path.getfilenamewithoutextension > path.getfullpath > path.getpathroot > path.gettempfilename > path.gettemppath > path.hasextension > path.ispathrooted > > Ian > > William E Caputo wrote: > > >(This is a resend. I didn't see it come across the list the first time I > >sent it. My apologies if it comes through twice) > > > >Hi All, > > > >Attached is a zip file containing a task called path. This task extracts > >path information from a given partial (or complete) path name and > >optionally expands it to a fully-qualified path, using either the current > >working directory or the Project's base directory as the root, and places > >in a designated property. > > > >I looked through the list of tasks and didn't see anything that did > >something like this (and we needed it) so after implementing it in a > >script task, I decided to code it up as a full-fledged task and submit it > >in the hope that it will be useful to others. > > > >I wrote it is as being in the Nant.Core namespace because that is where > >copy and mkdir are (and we seem to always be manipulating paths in our > >build files) but if the project's admins prefer that it be a somewhere > >else in NAnt or submitted to NAntContrib instead that is fine by me (I > >didn't cross post, but I will send it to that list if you like). > > > >The task is accompanied by 12 tests, and is fully documented. > > > >Best, > >Bill > > > >William E. Caputo > >ThoughtWorks, Inc. > >http://www.williamcaputo.com > > > >idia ktesis, koine chresis > > > >Hi All, > > > >Attached is a zip file containing a task called path. This task extracts > >path information from a given partial (or complete) path name and > >optionally expands it to a fully-qualified path, using either the current > >working directory or the Project's base directory as the root, and places > >in a designated property. > > > >I looked through the list of tasks and didn't see anything that did > >something like this (and we needed it) so after implementing it in a > >script task, I decided to code it up as a full-fledged task and submit it > >in the hope that it will be useful to others. > > > >I wrote it is as being in the Nant.Core namespace because that is where > >copy and mkdir are (and we seem to always be manipulating paths in our > >build files) but if the project's admins prefer that it be a somewhere > >else in NAnt or submitted to NAntContrib instead that is fine by me (I > >didn't cross post, but I will send it to that list if you like). > > > >The task is accompanied by 12 tests, and is fully documented. > > > >Best, > >Bill > > > >William E. Caputo > >ThoughtWorks, Inc. > >http://www.williamcaputo.com > > > >idia ktesis, koine chresis > > > > > > > > > > > -- > Ian MacLean, Developer, > ActiveState, a division of Sophos > http://www.ActiveState.com > > > >
Re: [nant-dev] SUBMISSION: Path Task
Ian MacLean:
>This looks good William. However I'm thinking that the new function
>support will be easier to use to do this kind of stuff.
Sounds good -- and I agree it will be easier to use that way. Looking
forward to seeing that in the next version! :-)
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
idia ktesis, koine chresis
Ian MacLean <[EMAIL PROTECTED]>
12/13/2003 10:38 PM
To: William E Caputo <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject:Re: [nant-dev] SUBMISSION: Path Task
This looks good William. However I'm thinking that the new function
support will be easier to use to do this kind of stuff.
the following path related functions will be included:
path.changeextension
path.combine
path.getdirectoryname
path.getextension
path.getfilename
path.getfilenamewithoutextension
path.getfullpath
path.getpathroot
path.gettempfilename
path.gettemppath
path.hasextension
path.ispathrooted
Ian
William E Caputo wrote:
>(This is a resend. I didn't see it come across the list the first time I
>sent it. My apologies if it comes through twice)
>
>Hi All,
>
>Attached is a zip file containing a task called path. This task extracts
>path information from a given partial (or complete) path name and
>optionally expands it to a fully-qualified path, using either the current
>working directory or the Project's base directory as the root, and places
>in a designated property.
>
>I looked through the list of tasks and didn't see anything that did
>something like this (and we needed it) so after implementing it in a
>script task, I decided to code it up as a full-fledged task and submit it
>in the hope that it will be useful to others.
>
>I wrote it is as being in the Nant.Core namespace because that is where
>copy and mkdir are (and we seem to always be manipulating paths in our
>build files) but if the project's admins prefer that it be a somewhere
>else in NAnt or submitted to NAntContrib instead that is fine by me (I
>didn't cross post, but I will send it to that list if you like).
>
>The task is accompanied by 12 tests, and is fully documented.
>
>Best,
>Bill
>
>William E. Caputo
>ThoughtWorks, Inc.
>http://www.williamcaputo.com
>
>idia ktesis, koine chresis
>
>Hi All,
>
>Attached is a zip file containing a task called path. This task extracts
>path information from a given partial (or complete) path name and
>optionally expands it to a fully-qualified path, using either the current
>working directory or the Project's base directory as the root, and places
>in a designated property.
>
>I looked through the list of tasks and didn't see anything that did
>something like this (and we needed it) so after implementing it in a
>script task, I decided to code it up as a full-fledged task and submit it
>in the hope that it will be useful to others.
>
>I wrote it is as being in the Nant.Core namespace because that is where
>copy and mkdir are (and we seem to always be manipulating paths in our
>build files) but if the project's admins prefer that it be a somewhere
>else in NAnt or submitted to NAntContrib instead that is fine by me (I
>didn't cross post, but I will send it to that list if you like).
>
>The task is accompanied by 12 tests, and is fully documented.
>
>Best,
>Bill
>
>William E. Caputo
>ThoughtWorks, Inc.
>http://www.williamcaputo.com
>
>idia ktesis, koine chresis
>
>
>
>
--
Ian MacLean, Developer,
ActiveState, a division of Sophos
http://www.ActiveState.com
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SUBMISSION: Path Task
This looks good William. However I'm thinking that the new function support will be easier to use to do this kind of stuff. the following path related functions will be included: path.changeextension path.combine path.getdirectoryname path.getextension path.getfilename path.getfilenamewithoutextension path.getfullpath path.getpathroot path.gettempfilename path.gettemppath path.hasextension path.ispathrooted Ian William E Caputo wrote: (This is a resend. I didn't see it come across the list the first time I sent it. My apologies if it comes through twice) Hi All, Attached is a zip file containing a task called path. This task extracts path information from a given partial (or complete) path name and optionally expands it to a fully-qualified path, using either the current working directory or the Project's base directory as the root, and places in a designated property. I looked through the list of tasks and didn't see anything that did something like this (and we needed it) so after implementing it in a script task, I decided to code it up as a full-fledged task and submit it in the hope that it will be useful to others. I wrote it is as being in the Nant.Core namespace because that is where copy and mkdir are (and we seem to always be manipulating paths in our build files) but if the project's admins prefer that it be a somewhere else in NAnt or submitted to NAntContrib instead that is fine by me (I didn't cross post, but I will send it to that list if you like). The task is accompanied by 12 tests, and is fully documented. Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com idia ktesis, koine chresis Hi All, Attached is a zip file containing a task called path. This task extracts path information from a given partial (or complete) path name and optionally expands it to a fully-qualified path, using either the current working directory or the Project's base directory as the root, and places in a designated property. I looked through the list of tasks and didn't see anything that did something like this (and we needed it) so after implementing it in a script task, I decided to code it up as a full-fledged task and submit it in the hope that it will be useful to others. I wrote it is as being in the Nant.Core namespace because that is where copy and mkdir are (and we seem to always be manipulating paths in our build files) but if the project's admins prefer that it be a somewhere else in NAnt or submitted to NAntContrib instead that is fine by me (I didn't cross post, but I will send it to that list if you like). The task is accompanied by 12 tests, and is fully documented. Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com idia ktesis, koine chresis -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
