From: William E C. <WEC...@th...> - 2003-12-14 02:33:22
Attachments:
PathTask.zip
|
(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 |
From: Ian M. <ianm@ActiveState.com> - 2003-12-14 04:41:02
|
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 |
From: Gert D. <ger...@pa...> - 2003-12-14 10:21:50
|
<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" <ianm@ActiveState.com> To: "William E Caputo" <WEC...@th...> Cc: <nan...@li...> 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 > nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers > > |
From: Jaroslaw K. <ja...@zd...> - 2003-12-14 10:48:56
|
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" <ger...@pa...> To: "Ian MacLean" <ianm@ActiveState.com>; "William E Caputo" <WEC...@th...> Cc: "Nant-Developers (E-Mail)" <nan...@li...> 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" <ianm@ActiveState.com> > To: "William E Caputo" <WEC...@th...> > Cc: <nan...@li...> > 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 > > nan...@li... > > 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 > nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers > |
From: Gert D. <ger...@pa...> - 2003-12-14 10:55:48
|
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" <ja...@zd...> To: "Gert Driesen" <ger...@pa...>; "Ian MacLean" <ianm@ActiveState.com>; "William E Caputo" <WEC...@th...> Cc: "Nant-Developers (E-Mail)" <nan...@li...> 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" <ger...@pa...> > To: "Ian MacLean" <ianm@ActiveState.com>; "William E Caputo" > <WEC...@th...> > Cc: "Nant-Developers (E-Mail)" <nan...@li...> > 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" <ianm@ActiveState.com> > > To: "William E Caputo" <WEC...@th...> > > Cc: <nan...@li...> > > 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 > > > nan...@li... > > > 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 > > nan...@li... > > https://lists.sourceforge.net/lists/listinfo/nant-developers > > > > > |
From: Ian M. <ianm@ActiveState.com> - 2003-12-14 11:25:43
|
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" <ja...@zd...> >To: "Gert Driesen" <ger...@pa...>; "Ian MacLean" ><ianm@ActiveState.com>; "William E Caputo" <WEC...@th...> >Cc: "Nant-Developers (E-Mail)" <nan...@li...> >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" <ger...@pa...> >>To: "Ian MacLean" <ianm@ActiveState.com>; "William E Caputo" >><WEC...@th...> >>Cc: "Nant-Developers (E-Mail)" <nan...@li...> >>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" <ianm@ActiveState.com> >>>To: "William E Caputo" <WEC...@th...> >>>Cc: <nan...@li...> >>>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 >>>>nan...@li... >>>>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 >>>nan...@li... >>>https://lists.sourceforge.net/lists/listinfo/nant-developers >>> >>> >>> >> >> >> -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com |
From: Jaroslaw K. <ja...@zd...> - 2003-12-14 11:44:42
|
> 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="aaaa" /> would become <if test="${aaaa}" /> <if propertyexists="aaaa" /> would become <if test=${nant::property-exists('aaaa')}" /> <if targetexists="aaaa" /> would become <if test=${nant::target-exists('aaaa')}" /> <ifnot> should be eliminated, because you can always write "not" in expressions. So: <ifnot propertytrue="aaaa"/> would become <if test="${not aaaa}" /> <ifnot propertyexists="aaaa"/> would become <if test="${not nant::property-exists('aaaa')}" /> <ifnot targetexists="aaaa"/> would become <if test="${not nant::target-exists('aaaa')}" /> 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 |
From: Ian M. <ianm@ActiveState.com> - 2003-12-14 12:00:44
|
+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="aaaa" /> would become <if test="${aaaa}" /> ><if propertyexists="aaaa" /> would become <if >test=${nant::property-exists('aaaa')}" /> ><if targetexists="aaaa" /> would become <if >test=${nant::target-exists('aaaa')}" /> > ><ifnot> should be eliminated, because you can always write "not" in >expressions. > >So: > ><ifnot propertytrue="aaaa"/> would become <if test="${not aaaa}" /> ><ifnot propertyexists="aaaa"/> would become <if test="${not >nant::property-exists('aaaa')}" /> ><ifnot targetexists="aaaa"/> would become <if test="${not >nant::target-exists('aaaa')}" /> > >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 >nan...@li... >https://lists.sourceforge.net/lists/listinfo/nant-developers > > -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com |
From: Jaroslaw K. <ja...@zd...> - 2003-12-14 12:33:28
|
Should I add Deprecated attribute to "propertyexists", "propertytrue" and "taskexists" in EE-patches? Jarek ----- Original Message ----- From: "Ian MacLean" <ianm@ActiveState.com> To: "Jaroslaw Kowalski" <ja...@zd...> Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" <WEC...@th...>; "Nant-Developers (E-Mail)" <nan...@li...> 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="aaaa" /> would become <if test="${aaaa}" /> > ><if propertyexists="aaaa" /> would become <if > >test=${nant::property-exists('aaaa')}" /> > ><if targetexists="aaaa" /> would become <if > >test=${nant::target-exists('aaaa')}" /> > > > ><ifnot> should be eliminated, because you can always write "not" in > >expressions. > > > >So: > > > ><ifnot propertytrue="aaaa"/> would become <if test="${not aaaa}" /> > ><ifnot propertyexists="aaaa"/> would become <if test="${not > >nant::property-exists('aaaa')}" /> > ><ifnot targetexists="aaaa"/> would become <if test="${not > >nant::target-exists('aaaa')}" /> > > > >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 > >nan...@li... > >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 > nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers > |
From: Ian M. <ianm@ActiveState.com> - 2003-12-14 13:16:04
|
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" <ianm@ActiveState.com> >To: "Jaroslaw Kowalski" <ja...@zd...> >Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" ><WEC...@th...>; "Nant-Developers (E-Mail)" ><nan...@li...> >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="aaaa" /> would become <if test="${aaaa}" /> >>><if propertyexists="aaaa" /> would become <if >>>test=${nant::property-exists('aaaa')}" /> >>><if targetexists="aaaa" /> would become <if >>>test=${nant::target-exists('aaaa')}" /> >>> >>><ifnot> should be eliminated, because you can always write "not" in >>>expressions. >>> >>>So: >>> >>><ifnot propertytrue="aaaa"/> would become <if test="${not aaaa}" /> >>><ifnot propertyexists="aaaa"/> would become <if test="${not >>>nant::property-exists('aaaa')}" /> >>><ifnot targetexists="aaaa"/> would become <if test="${not >>>nant::target-exists('aaaa')}" /> >>> >>>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 >>>nan...@li... >>>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 >>nan...@li... >>https://lists.sourceforge.net/lists/listinfo/nant-developers >> >> >> -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com |
From: Jaroslaw K. <ja...@zd...> - 2003-12-14 14:09:12
|
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" <ianm@ActiveState.com> To: "Jaroslaw Kowalski" <ja...@zd...> Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" <WEC...@th...>; "Nant-Developers (E-Mail)" <nan...@li...> 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" <ianm@ActiveState.com> > >To: "Jaroslaw Kowalski" <ja...@zd...> > >Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" > ><WEC...@th...>; "Nant-Developers (E-Mail)" > ><nan...@li...> > >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="aaaa" /> would become <if test="${aaaa}" /> > >>><if propertyexists="aaaa" /> would become <if > >>>test=${nant::property-exists('aaaa')}" /> > >>><if targetexists="aaaa" /> would become <if > >>>test=${nant::target-exists('aaaa')}" /> > >>> > >>><ifnot> should be eliminated, because you can always write "not" in > >>>expressions. > >>> > >>>So: > >>> > >>><ifnot propertytrue="aaaa"/> would become <if test="${not aaaa}" /> > >>><ifnot propertyexists="aaaa"/> would become <if test="${not > >>>nant::property-exists('aaaa')}" /> > >>><ifnot targetexists="aaaa"/> would become <if test="${not > >>>nant::target-exists('aaaa')}" /> > >>> > >>>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 > >>>nan...@li... > >>>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 > >>nan...@li... > >>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 > nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers > |
From: Gert D. <ger...@pa...> - 2003-12-14 15:55:47
|
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" <ja...@zd...> To: "Ian MacLean" <ianm@ActiveState.com> Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" <WEC...@th...>; "Nant-Developers (E-Mail)" <nan...@li...> 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" <ianm@ActiveState.com> > To: "Jaroslaw Kowalski" <ja...@zd...> > Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" > <WEC...@th...>; "Nant-Developers (E-Mail)" > <nan...@li...> > 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" <ianm@ActiveState.com> > > >To: "Jaroslaw Kowalski" <ja...@zd...> > > >Cc: "Gert Driesen" <ger...@pa...>; "William E Caputo" > > ><WEC...@th...>; "Nant-Developers (E-Mail)" > > ><nan...@li...> > > >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="aaaa" /> would become <if test="${aaaa}" /> > > >>><if propertyexists="aaaa" /> would become <if > > >>>test=${nant::property-exists('aaaa')}" /> > > >>><if targetexists="aaaa" /> would become <if > > >>>test=${nant::target-exists('aaaa')}" /> > > >>> > > >>><ifnot> should be eliminated, because you can always write "not" in > > >>>expressions. > > >>> > > >>>So: > > >>> > > >>><ifnot propertytrue="aaaa"/> would become <if test="${not aaaa}" /> > > >>><ifnot propertyexists="aaaa"/> would become <if test="${not > > >>>nant::property-exists('aaaa')}" /> > > >>><ifnot targetexists="aaaa"/> would become <if test="${not > > >>>nant::target-exists('aaaa')}" /> > > >>> > > >>>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 > > >>>nan...@li... > > >>>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 > > >>nan...@li... > > >>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 > > nan...@li... > > 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 > nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers > > |
From: Jaroslaw K. <ja...@zd...> - 2003-12-14 18:03:49
|
> > 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 |
From: Ian M. <ianm@ActiveState.com> - 2003-12-15 03:12:07
|
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 >nan...@li... >https://lists.sourceforge.net/lists/listinfo/nant-developers > > |
From: Gert D. <ger...@pa...> - 2003-12-15 07:03:54
|
----- Original Message ----- From: "Ian MacLean" <ianm@ActiveState.com> To: "Jaroslaw Kowalski" <ja...@zd...> Cc: "Gert Driesen" <ger...@pa...>; "Nant-Developers (E-Mail)" <nan...@li...> 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 |
From: Martin A. <mar...@go...> - 2003-12-19 14:26:01
|
Hi, > 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 ... I (and Ian+Jarek as well I hope) am very pleased that you are taking care about future of NAnt. It is very important! NAnt community is more then willing to contribute many nice features but not all of them could be incorporated to remain consistent and useful tool. Expression will be good addion IMO. This new feature definetelly change semantics of our build files. What we should assure now is to be good change. That is why I protest against obsoleting dashes and certaily also why you are thinking about task/function difference. 2/ +1 for obsoleting some tasks like <avaiable> etc (see Jarek's mail) but please, do not remove it completely (atleast up to 1.0). Just mark it with obsolete attribute. 3/ I'm also thinking about fileset support. Could be possible to extend relation between tasks/types/functions? I mean, many tasks now use filesets. What about functions? Could be nice in some cases... E.g.: <fileset id='f1'> <!-- define fileset --> <includeList ...> </fileset> ... <foreach ... property="dir"> <if test="${ not fileset::contains(f1,dir)"> <fileset id='f1'> <!-- extend existing fileset --> <include name="${dir}"/> </fileset> </if> </foreach> ... <!-- use fileset --> Other types could be simmilar... Regards, Martin |
From: Jaroslaw K. <ja...@zd...> - 2003-12-19 14:49:26
|
> 3/ > I'm also thinking about fileset support. Could be possible to extend > relation between tasks/types/functions? I mean, many tasks now use filesets. > What about functions? Could be nice in some cases... E.g.: > > <fileset id='f1'> <!-- define fileset --> > <includeList ...> > </fileset> > ... > <foreach ... property="dir"> > <if test="${ not fileset::contains(f1,dir)"> > <fileset id='f1'> <!-- extend existing fileset --> > <include name="${dir}"/> > </fileset> > </if> > </foreach> > ... > <!-- use fileset --> This can be easily done because expression evaluator is able to handle values and expressions of almost any type. One concern only: should "f1" in your example go like that? Shouldn't we prefix it with something, like: <if test="${not fileset::contains(fileset::get-by-name('f1'),dir)}"> </if> I think it's better not to change the semantics of simple names, like "f1" because today they mean "properties" and nothing else. Jarek |
From: Jaroslaw K. <ja...@zd...> - 2003-12-19 14:56:36
|
BTW. Expression support is in the latest daily build, so you should be able to try it out. It's also in CVS HEAD now. You can play with functions and fileset support. It could be an interesting addition to NAnt. Jarek ----- Original Message ----- From: "Jaroslaw Kowalski" <ja...@zd...> To: "Martin Aliger" <mar...@go...>; "! nant" <nan...@li...> Sent: Friday, December 19, 2003 3:49 PM Subject: Re: [nant-dev] EE + types support [was SUBMISSION: Path Task] > > 3/ > > I'm also thinking about fileset support. Could be possible to extend > > relation between tasks/types/functions? I mean, many tasks now use > filesets. > > What about functions? Could be nice in some cases... E.g.: > > > > <fileset id='f1'> <!-- define fileset --> > > <includeList ...> > > </fileset> > > ... > > <foreach ... property="dir"> > > <if test="${ not fileset::contains(f1,dir)"> > > <fileset id='f1'> <!-- extend existing fileset --> > > <include name="${dir}"/> > > </fileset> > > </if> > > </foreach> > > ... > > <!-- use fileset --> > > This can be easily done because expression evaluator is able to handle > values and expressions of almost any type. One concern only: should "f1" in > your example go like that? Shouldn't we prefix it with something, like: > > <if test="${not fileset::contains(fileset::get-by-name('f1'),dir)}"> > </if> > > I think it's better not to change the semantics of simple names, like "f1" > because today they mean "properties" and nothing else. > > Jarek > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > nant-developers mailing list > nan...@li... > https://lists.sourceforge.net/lists/listinfo/nant-developers > |
From: Martin A. <mar...@go...> - 2003-12-23 15:03:18
|
> This can be easily done because expression evaluator is able to handle > values and expressions of almost any type. One concern only: should "f1" in > your example go like that? Shouldn't we prefix it with something, like: > > <if test="${not fileset::contains(fileset::get-by-name('f1'),dir)}"> > </if> > > I think it's better not to change the semantics of simple names, like "f1" > because today they mean "properties" and nothing else. Sure. Agree. I'll propably play with it after holidays. Mery christmas to all! Martin |
From: Ian M. <ianm@ActiveState.com> - 2003-12-14 11:20:58
|
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 <property name="full.path" value="path.getfullpath('../../bar')" /> vs <path property="full.path" partial="foo\bar\file.txt"/> or <path property="partial.path" fullpath="false" pathonly="true" partial="foo\bar\file.txt"/> 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: ><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" <ianm@ActiveState.com> >To: "William E Caputo" <WEC...@th...> >Cc: <nan...@li...> >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 >>> >>> >>> >>> >>> >>> |
From: Stefan B. <ste...@fr...> - 2003-12-15 07:46:39
|
On Sun, 14 Dec 2003, Gert Driesen <ger...@pa...> 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 |
From: Ian M. <ianm@ActiveState.com> - 2003-12-15 08:01:31
|
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 <which> 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 <ger...@pa...> 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 >nan...@li... >https://lists.sourceforge.net/lists/listinfo/nant-developers > > -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com |
From: Stefan B. <ste...@fr...> - 2003-12-15 08:09:46
|
On Mon, 15 Dec 2003, Ian MacLean <ia...@ac...> 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 |