Re: [nant-dev] FileSetCollection and the copy task questions
Martin Aliger: We are currently extending fileset to enable add something to existing fileset. Yes, that would work for the example I sent (I thought about your recent posts after I sent my email). After sending, I realized that the refactoring I was doing also needed to do something like this (for which I don't think the redefining modification is enough): copy todir=\foo\one fileset refid=common.files / fileset refid=less.common.files / /copy copy todir=\foo\two fileset refid=common.files / fileset refid=other.common.files / /copy copy todir=\foo\two fileset refid=other.common.files / fileset refid=less.common.files / /copy (etc) In short, I have somewhere between 3 and 5 discrete blocks of assemblies that have to be copied to something like 10 different directories, in various combinations that make it impossible (as far as I can see) to get rid of the redundancy with single filesets. Unless, the new mods support multiple refid's? (that would remove the need for multiple fileets -- at least in my case). E.g.: copy todir=\foo\two fileset refid=common.files refid=other.common.files mode=append / /copy or perhaps: copy todir=\foo\two mode=append fileset refidcommon.files/refid refidother.common.files/refid /fileset /copy If not (and I am assuming not, from what I've seen so far), I would be interested in people's opinions on the preferred way -- multiple refid's or multiple filesets (or both, or something else)? Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com idia ktesis, koine chresis --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] FileSetCollection and the copy task questions
Hi All,
I am making sure I am not missing anything. I would like to use the copy
task with multiple filesets like so:
copy
todir=${project.source.root}\${application.architecture.serviceinterface.bin.directory}
fileset refid=common.files /
fileset basedir=${other.files.dir}
includes name=**.foo /
/fileset
/copy
The advantage of being able to do this is to be better able to factor out
duplication (without having to duplicate otherwise identical copy tasks,
that could eventually get separated in the build file).
So, realizing that it wasn't there, I set out to add it, and I want to get
some feedback first. Here are my assumptions/questions that I want
confirmed/answered:
1) Should I use BuildElementArray or BuildElementCollection
2) There doesn't appear to be a FileSetCollection is that correct?
3) If so, is there any big issue that has prevented the creation of one
(i.e. has someone tried?) or is it that it just hasn't been needed yet?
4) The CopyTask currently accesses a single FileSet, assuming a
FileSetCollection existed, it appears that factoring the code that
accesses this single fileset into a method called in a loop iterating
across the fileset collection will provide the desired result -- anyone
see any reason why not?
Assuming I haven't missed anything, this looks like a relatively small
change, that would result in a generally useful type (i.e.
FileSetCollection) and the multi-fileset copy task. If this seems useful
(and we get time to make the change) I will submit it back, if the nant
team finds it useful.
Thoughts?
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
idia ktesis, koine chresis
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
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
[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
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
[nant-dev] Re: [NAntC-Dev] 0.8.4 Beta
vssget task changes are good to go. Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com idia ktesis, koine chresis Gert Driesen [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/26/2003 01:21 PM To: Nant-Developers (E-Mail) [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject:[NAntC-Dev] 0.8.4 Beta Hi, I'd like to ensure that the release notes for both NAnt and NAntContrib are complete. Can everyone that contributed code to NAnt and NAntContrib since the 0.8.3 release double-check whether the release notes (/doc/releasenotes.html in NAnt/NAntContrib cvs or /releasenotes.html on the NAnt and NAntContrib websites) are complete and correct ? Please validate the updated XHTML using the W3C MarkUp Validation Service (http://validator.w3.org/) if you make changes to make sure we keep the html docs XHTML 1.1 compliant ... Things that still need to be added (that I know of) are : - changes to cvs tasks (Clayton, can you take care of this ?) - changes to solution task (I'm thinking of webmap support and stuff) But I'm probable missing some stuff, so feel free to correct me (and the release notes) ... Thanks, 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/ ___ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer --- 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] Expansion of properties in target descriptions
Hi All, I realize this is not implemented, and I am not even sure if it should be, but I was wondering if someone could point me in the right direction for figuring out if it easily could be done. As near as I can tell, projecthelp is extracted using an xslt that is executed completely independent of the parsing of targets. So, the three things I am trying to determine right now are: 1) Where in the code are the properties expanded into their values for use in tasks? 2) Would doing this before transforming for projecthelp be of any value, or (as I suspect) is it done in the parsed data, and so would have no impact 3) What would need to be done to change projecthelp to work off of the parsed target information (assuming again that this includes the description). If anyone can save me a bit of time by pointing me at the right classes to look at so I can find the answers, that would be much appreciated. Also, if it turns out to be feasible, is this something that the nant team would be interested in having, or is this considered counter to the design goals of the tool in some way? Best, Bill William E. Caputo ThoughtWorks, Inc. http://www.twelve71.com/caputo/ Continuous Integration: Watchin' the hella tech ta' boost da' shiggety shiggety shwa. --- 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] RE: NAntContrib update
Tomas: That said, I'd like to take the opportunity to vent something that has been nagging me for a while An excellent description of your frustration, Tomas. I think it is important for the users of a system to explain to its creators what is bothering them. I want to make a couple of comments, but I want to stress first that I understand and even agree with many of your comments, and I don't want to imply that you shouldn't have made them... All the continuous NAnt restructuring... I'm going to be brutally honest here: Even though no 1.0 release of nant has ever been done, it has been used by people to build *real* systems for a really long time now. As you say, NAnt is not yet at 1.0, isn't it an unrealistic expectation of us early adopters to use a pre-1.0 release and constrain its developers not to change the system radically as they learn new things in order to get the product to 1.0? My big point is that many of the changes were done with little or no regard to the impact they might have on code outside the actual nant code base, and that's a problem now. One I personally consider a serious one. Again pre-1.0, an extension mechanism and general architecture that works well, is clear and is maintainable outweighs backward compatibility IMO. As an early adopter (who has written custom tasks as well) I fully expect this. Further, I also know that I don't *have* to upgrade. If I have that software working on a real project, I can use that version, migrating my tasks (if they are generic enough for reuse) at a later date, when the architecture stabilizes (which I would expect in the 1.0 version of NAnt). If you want people to use nant effectively, and be able to take advantage of what new builds of Nant offers easily, you need to start taking into consideration just how easy is going to migrate to a new build, and that takes far more than simply ensuring the .build files are valid. Again, after the 1.0 release, I would agree with this. But prior to that, ease of use, and adoption are IMHO more important goals. NAnt has the potential to be *the* definitive build tool for the .NET platform, but it won't be if it isn't as easy to use, understand, and install as possible. Constraining these with backward compatibility issues before the 1.0 release will make this a lot less likely to happen. NAnt has a much bigger hill to climb than Ant ever did to become a standard in the MS world. We at ThoughtWorks are engaged with clients who are looking for build solutions for .NET, and we are pushing NAnt as the answer to their needs. Right now the biggest barrier to adoption are things like the NAntContrib problem, the ease of use of VS -- not backward compatibility. Some of them want to see a 1.0 version before they will adopt. All of them want a simple turnkey installation, and a clear architecture. Finding the best solution to NAnt's architectural and deployment needs IMO outweighs backward compatibility at this time if NAnt is going to have wide appeal in the VS-dominated world of the MS shops out there. I would rather see radical changes in the code base as the NAnt developers improve the design, than see them stop short of optimal in the name of backward compatibility for what test versions of the code base (which is clear by the lack of 1.0 designation, and the attitude of the project members). Best, Bill William E. Caputo ThoughtWorks, Inc. Its the foolish cat that looks at the finger when it is pointing at the food --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] FW: Upcoming 0.8.3 release
Matt: Is it alright to do a couple of pre-0.8.3 builds before the real one (at least one)? In light of this, and Gert's request to fit more features in before releasing, I wonder if NAnt might not benefit from doing time-boxed, instead of feature-boxed releases. If the project were to release an update every n weeks, then it wouldn't matter so much if features didn't make the cut (Gert's suggestion) since they will be in the next release in say 3 weeks, while bug fixes and other issue resolution (i.e. Matt's pre-release versions) can have numbered builds of 0.8.2.x (allowing you to mark 0.8.3 as the stablest version since 8.2 and then starting again with 0.8.3.x) Of course this would put additional importance on keeping the tests passing all the time (and having more tests), but that is probably not a bad thing. Just a suggestion. Best, Bill William E. Caputo ThoughtWorks, Inc. Its the foolish cat that looks at the finger when it is pointing at the food --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
