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
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 which or something close (like Unix's which utility that says where on your PATH a given command exists). Ant already has whichresource in CVS HEAD and ISTR there also is/was a whichfile, but I don't remember where. Basically, the which task in Ant would do the same as available - i.e. look the file up in a given path - 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
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.
property name=foo location=bar/
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
You'd probably want to call it loadextensions / 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 haveloadtasks scan for all nant objects - it might need renaming in that case. Maybe loadcustom 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
Sounds good to me. Thanks ! Ian Damir Simunic wrote: You'd probably want to call it loadextensions / 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 haveloadtasks scan for all nant objects - it might need renaming in that case. Maybe loadcustom 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
start-rant 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 ... /end-rant 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 --- 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
Re: [nant-dev] SUBMISSION: Path Task
We already have tasks:
sysinfo
tstamp
available
if
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:
property name=somepath value=c:\temp\test.txt /
property name=basename
value=${path::get-file-name-without-extension(somepath)} /
It's both readable and can be used in all places, like CSC task:
csc output=${path::combine(path::get-directory-name(somefile),
'outputfile.dll')}
...
/csc
or:
csc output=${path::get-directory-name(somefile)}/outputfile.dll
...
/csc
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
start-rant
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 ...
/end-rant
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
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:
sysinfo
tstamp
available
if
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:
property name=somepath value=c:\temp\test.txt /
property name=basename
value=${path::get-file-name-without-extension(somepath)} /
It's both readable and can be used in all places, like CSC task:
csc output=${path::combine(path::get-directory-name(somefile),
'outputfile.dll')}
...
/csc
or:
csc output=${path::get-directory-name(somefile)}/outputfile.dll
...
/csc
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
start-rant
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 ...
/end-rant
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
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:
sysinfo
tstamp
available
if
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:
property name=somepath value=c:\temp\test.txt /
property name=basename
value=${path::get-file-name-without-extension(somepath)} /
It's both readable and can be used in all places, like CSC task:
csc output=${path::combine(path::get-directory-name(somefile),
'outputfile.dll')}
...
/csc
or:
csc output=${path::get-directory-name(somefile)}/outputfile.dll
...
/csc
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
start-rant
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 ...
/end-rant
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
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:
call
description
fail
if
ifnot
include
loadtasks
nant
property
script
These should be definitely kept.
2. I would consider removing any task that is neither used to direct the
build process nor noes something - as described above.
My candidates for removal are:
sysinfo
tstamp
available
3. I'm also thinking about removing:
readregistry(maybe not, because it can be used to read many values at
once)
xmlpeek (maybe not, because it's a nice pair to xmlpoke)
4. I also think that if should be restructured to include only test
attribute.
if propertytrue= / would become if test=${} /
if propertyexists= / would become if
test=${nant::property-exists('')} /
if targetexists= / would become if
test=${nant::target-exists('')} /
ifnot should be eliminated, because you can always write not in
expressions.
So:
ifnot propertytrue=/ would become if test=${not } /
ifnot propertyexists=/ would become if test=${not
nant::property-exists('')} /
ifnot targetexists=/ would become if test=${not
nant::target-exists('')} /
5. There's a problem with uptodatefile, but I think this should go into
another task or a function. Like:
check-up-to-date property=
target-files
includes name=... /
/target-files
source-files
includes name=... /
/source-files
/check-up-to-date
A function that would be useful for single-file to single-file comparison:
if test=${file::is-newer-than('file1','file2')} /
6. With these changes we'd have an if task that would be clean and we'd
get rid of sysinfo, tstamp, available
7. All above syntax changes could be done automatically with the help of a
simple XSLT file that would rewrite buildfiles.
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
+1 on the if task refactoring. I'm not sure about removing sysinfo
though. I realize that a getenv() function would provide equivalent
functionality, however I like the fact that I just need to do
sysinfo/
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:
call
description
fail
if
ifnot
include
loadtasks
nant
property
script
These should be definitely kept.
2. I would consider removing any task that is neither used to direct the
build process nor noes something - as described above.
My candidates for removal are:
sysinfo
tstamp
available
3. I'm also thinking about removing:
readregistry(maybe not, because it can be used to read many values at
once)
xmlpeek (maybe not, because it's a nice pair to xmlpoke)
4. I also think that if should be restructured to include only test
attribute.
if propertytrue= / would become if test=${} /
if propertyexists= / would become if
test=${nant::property-exists('')} /
if targetexists= / would become if
test=${nant::target-exists('')} /
ifnot should be eliminated, because you can always write not in
expressions.
So:
ifnot propertytrue=/ would become if test=${not } /
ifnot propertyexists=/ would become if test=${not
nant::property-exists('')} /
ifnot targetexists=/ would become if test=${not
nant::target-exists('')} /
5. There's a problem with uptodatefile, but I think this should go into
another task or a function. Like:
check-up-to-date property=
target-files
includes name=... /
/target-files
source-files
includes name=... /
/source-files
/check-up-to-date
A function that would be useful for single-file to single-file comparison:
if test=${file::is-newer-than('file1','file2')} /
6. With these changes we'd have an if task that would be clean and we'd
get rid of sysinfo, tstamp, available
7. All above syntax changes could be done automatically with the help of a
simple XSLT file that would rewrite buildfiles.
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
--
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
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 sysinfo
though. I realize that a getenv() function would provide equivalent
functionality, however I like the fact that I just need to do
sysinfo/
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:
call
description
fail
if
ifnot
include
loadtasks
nant
property
script
These should be definitely kept.
2. I would consider removing any task that is neither used to direct the
build process nor noes something - as described above.
My candidates for removal are:
sysinfo
tstamp
available
3. I'm also thinking about removing:
readregistry(maybe not, because it can be used to read many values
at
once)
xmlpeek (maybe not, because it's a nice pair to xmlpoke)
4. I also think that if should be restructured to include only test
attribute.
if propertytrue= / would become if test=${} /
if propertyexists= / would become if
test=${nant::property-exists('')} /
if targetexists= / would become if
test=${nant::target-exists('')} /
ifnot should be eliminated, because you can always write not in
expressions.
So:
ifnot propertytrue=/ would become if test=${not } /
ifnot propertyexists=/ would become if test=${not
nant::property-exists('')} /
ifnot targetexists=/ would become if test=${not
nant::target-exists('')} /
5. There's a problem with uptodatefile, but I think this should go into
another task or a function. Like:
check-up-to-date property=
target-files
includes name=... /
/target-files
source-files
includes name=... /
/source-files
/check-up-to-date
A function that would be useful for single-file to single-file
comparison:
if test=${file::is-newer-than('file1','file2')} /
6. With these changes we'd have an if task that would be clean and we'd
get rid of sysinfo, tstamp, available
7. All above syntax changes could be done automatically with the help of
a
simple XSLT file that would rewrite buildfiles.
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
--
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
---
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
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 sysinfo
though. I realize that a getenv() function would provide equivalent
functionality, however I like the fact that I just need to do
sysinfo/
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:
call
description
fail
if
ifnot
include
loadtasks
nant
property
script
These should be definitely kept.
2. I would consider removing any task that is neither used to direct the
build process nor noes something - as described above.
My candidates for removal are:
sysinfo
tstamp
available
3. I'm also thinking about removing:
readregistry(maybe not, because it can be used to read many values
at
once)
xmlpeek (maybe not, because it's a nice pair to xmlpoke)
4. I also think that if should be restructured to include only test
attribute.
if propertytrue= / would become if test=${} /
if propertyexists= / would become if
test=${nant::property-exists('')} /
if targetexists= / would become if
test=${nant::target-exists('')} /
ifnot should be eliminated, because you can always write not in
expressions.
So:
ifnot propertytrue=/ would become if test=${not } /
ifnot propertyexists=/ would become if test=${not
nant::property-exists('')} /
ifnot targetexists=/ would become if test=${not
nant::target-exists('')} /
5. There's a problem with uptodatefile, but I think this should go into
another task or a function. Like:
check-up-to-date property=
target-files
includes name=... /
/target-files
source-files
includes name=... /
/source-files
/check-up-to-date
A function that would be useful for single-file to single-file
comparison:
if test=${file::is-newer-than('file1','file2')} /
6. With these changes we'd have an if task that would be clean and we'd
get rid of sysinfo, tstamp, available
7. All above syntax changes could be done automatically with the help of
a
simple XSLT file that would rewrite buildfiles.
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
--
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
--
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
Ok. Should we do something with uptodatefile before the merge? If we do so,
we can deprecate ifnot 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 sysinfo
though. I realize that a getenv() function would provide equivalent
functionality, however I like the fact that I just need to do
sysinfo/
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:
call
description
fail
if
ifnot
include
loadtasks
nant
property
script
These should be definitely kept.
2. I would consider removing any task that is neither used to direct
the
build process nor noes something - as described above.
My candidates for removal are:
sysinfo
tstamp
available
3. I'm also thinking about removing:
readregistry(maybe not, because it can be used to read many
values
at
once)
xmlpeek (maybe not, because it's a nice pair to xmlpoke)
4. I also think that if should be restructured to include only test
attribute.
if propertytrue= / would become if test=${} /
if propertyexists= / would become if
test=${nant::property-exists('')} /
if targetexists= / would become if
test=${nant::target-exists('')} /
ifnot should be eliminated, because you can always write not in
expressions.
So:
ifnot propertytrue=/ would become if test=${not } /
ifnot propertyexists=/ would become if test=${not
nant::property-exists('')} /
ifnot targetexists=/ would become if test=${not
nant::target-exists('')} /
5. There's a problem with uptodatefile, but I think this should go
into
another task or a function. Like:
check-up-to-date property=
target-files
includes name=... /
/target-files
source-files
includes name=... /
/source-files
/check-up-to-date
A function that would be useful for single-file to single-file
comparison:
if test=${file::is-newer-than('file1','file2')} /
6. With these changes we'd have an if task that would be clean and
we'd
get rid of sysinfo, tstamp, available
7. All above syntax changes could be done automatically with the help
of
a
simple XSLT file that would rewrite buildfiles.
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
--
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
--
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
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 ifnot as well ... I always
found the if and ifnot 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 ifnot 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 sysinfo
though. I realize that a getenv() function would provide equivalent
functionality, however I like the fact that I just need to do
sysinfo/
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:
call
description
fail
if
ifnot
include
loadtasks
nant
property
script
These should be definitely kept.
2. I would consider removing any task that is neither used to direct
the
build process nor noes something - as described above.
My candidates for removal are:
sysinfo
tstamp
available
3. I'm also thinking about removing:
readregistry(maybe not, because it can be used to read many
values
at
once)
xmlpeek (maybe not, because it's a nice pair to xmlpoke)
4. I also think that if should be restructured to include only
test
attribute.
if propertytrue= / would become if test=${} /
if propertyexists= / would become if
test=${nant::property-exists('')} /
if targetexists= / would become if
test=${nant::target-exists('')} /
ifnot should be eliminated, because you can always write not in
expressions.
So:
ifnot propertytrue=/ would become if test=${not } /
ifnot propertyexists=/ would become if test=${not
nant::property-exists('')} /
ifnot targetexists=/ would become if test=${not
nant::target-exists('')} /
5. There's a problem with uptodatefile, but I think this should go
into
another task or a function. Like:
check-up-to-date property=
target-files
includes name=... /
/target-files
source-files
includes name=... /
/source-files
/check-up-to-date
A function that would be useful for single-file to single-file
comparison:
if test=${file::is-newer-than('file1','file2')} /
6. With these changes we'd have an if task that would be clean and
we'd
get rid of sysinfo, tstamp, available
7. All above syntax changes could be done automatically with the help
of
a
simple XSLT file that would rewrite buildfiles.
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
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
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
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
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
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 - loadtasks I'm wondering if we should either : add two extra tasks loadtypes and loadfunctions or haveloadtasks scan for all nant objects - it might need renaming in that case. Maybe loadcustom 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 loadtasks 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 loadfunctions task. I'm also thinking about supporting functions written in a script. See attached code for actual code used to implement path::* functions. 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
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
[nant-dev] SUBMISSION: Path Task
(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 PathTask.zip Description: Zip archive
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
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
