RE: [nant-dev] SUBMISSION: Path Task
You'd probably want to call it loadextensions / then. Damir -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian MacLean Sent: Monday, December 15, 2003 4:06 AM To: Jaroslaw Kowalski Cc: Nant-Developers (E-Mail); William E Caputo Subject: Re: [nant-dev] SUBMISSION: Path Task or haveloadtasks scan for all nant objects - it might need renaming in that case. Maybe loadcustom or somthing like that. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Versions of nightly builds
I've noticed that nightly builds come with version number out of sync: just downloaded 0.8.4.31128, but properties of NAnt.exeshow 0.8.4.31114. Running nant -help shows 0.8.4.0. As a small convenience, do you think it would be possible to package the build in a version-numbered folder, similar to how .NET runtimes are installed? For example, instead of having nant.sln file in the root of the zip archive, it would be in NAnt\v0.8.4.31128\nant.sln. This way, it would be much easier to unpack files when using multiple copies at once. Damir
[nant-dev] fail task behavior and nant.onfailure
I've found some issues in handling forced failures in NAnt v0.8.4.31128. What happens is that I have a nant.onfailure task set. Somewhere in the build script, I'm failing the build with fail message=Failure reason / task. The onfailure handler calls a cleanup target that happens to have an error. If the call to the cleanup task does not have failonerror=false set, then the original fail message is never written out. (Scenario 1, failing-task.build). Not even the message BUILD FAILED is written at the end. On the other hand, if I set failonerror=false when calling tasks from the onfailure handler, I get the message from my fail task (line 20 in scenario 2), which is expected behavior, although it would be much more useful if the same message would also appear on the line 5 in scenario 2, not just at the end with a file line number (line 19). The worst problem is if the task fails in the onfailure handler itself (scenario 3, failing-task2.build file). The original failure message is never printed out, no matter how failonerror is set on the failing task. One would expect that the original fail message always appear, regardless whether further errors are reported after fail task triggered the failure. In addition, in all three scenarios any echo message after the fail task is never printed out; only [echo] appears in the output. (Scenario 1, line 12; Scenario 2 lines 12 and 15; Scenario 3 lines 9 and 10). I suppose this is a bug. Damir Scenario 1: onfailure handler calling failing 'cleanup' target with failonerror=true: === 1: Buildfile: file:///C:/failing-task.build 2: Target(s) specified: fail 3: 4: fail: 5: 6: 7: handle-failure: 8: 9: 10: cleanup: 11: 12: [echo] 13: C:\failing-task.build(21,4): 14: Property 'build.dir' has not been set. 15: 16: For more information regarding the cause of the build failure, enable log4net using the instructions in NAnt.exe.config and run the build again. 17: Try 'nant -help' for more information Scenario 2: onfailure handler calling failing 'cleanup' target with failonerror=false: 1: Buildfile: file:///C:/failing-task.build file:///C:/failing-task.build 2: Target(s) specified: fail 3: 4: fail: 5: 6: 7: handle-failure: 8: 9: 10: cleanup: 11: 12: [echo] 13: C:\failing-task.build(21,4): 14: Property 'build.dir' has not been set. 15: [echo] 16: 17: BUILD FAILED 18: 19: C:\failing-task.build(10,5): 20: === This message should announce the forced failure. 21: 22: Total time: 0.1 seconds. Scenario 3: onfailure handler calling failing 'delete' task with failonerror=false: = 1: Buildfile: file:///failing-task2.build file:///failing-task2.build 2: Target(s) specified: fail 3: 4:fail: 5: 6: 7:handle-failure: 8: 9: [echo] 10: [echo] 11: C:\failing-task2.build(16,4): 12: Property 'build.dir' has not been set. 13: 14: For more information regarding the cause of the build failure, enable log4net using the instructions in NAnt.exe.config and run the build again. 15: 16: Try 'nant -help' for more information failing-task.build Description: Binary data failing-task2.build Description: Binary data onfailure handler calling failing 'cleanup' target with failonerror=true: === 1: Buildfile: file:///C:/failing-task.build 2: Target(s) specified: fail 3: 4: fail: 5: 6: 7: handle-failure: 8: 9: 10: cleanup: 11: 12: [echo] 13: C:\failing-task.build(21,4): 14: Property 'build.dir' has not been set. 15: 16: For more information regarding the cause of the build failure, enable log4net using the instructions in NAnt.exe.config and run the build again. 17: Try 'nant -help' for more information onfailure handler calling failing 'cleanup' target with failonerror=false: 1: Buildfile: file:///C:/failing-task.build 2: Target(s) specified: fail 3: 4: fail: 5: 6: 7: handle-failure: 8: 9: 10: cleanup: 11: 12: [echo] 13: C:\failing-task.build(21,4): 14: Property 'build.dir' has not been set. 15: [echo] 16: 17: BUILD FAILED 18: 19: C:\failing-task.build(10,5): 20: === This message should announce the forced failure. 21: 22: Total time: 0.1 seconds. onfailure handler calling failing 'delete' task with failonerror=false: = 1: Buildfile: file:///failing-task2.build 2: Target(s) specified: fail 3: 4:fail: 5: 6: 7:handle-failure: 8: 9: [echo] 10: [echo] 11: C:\failing-task2.build(16,4): 12: Property 'build.dir' has not been set. 13: 14: For more information regarding the cause of the build failure, enable log4net using the
[nant-dev] Inconsistent behavior of include task?
I have 4 files: one in the root folder, three in a subfolder. In the root folder there is the main build file which includes one of the files in the subfolder. This other file includes another two. Thus: Main file has include buildfile="inc/included.build" / inc/included.build has: include buildfile="task1.build" / include buildfile="task2.build" / According to an email I found (http://www.geocrawler.com/archives/3/14603/2002/9/0/9638108/)the correct behavior for include is to set the included file's basedir to thebasedir of the file including it. This is pretty inconvenient, as the included file cannot include other files relative to it, that is, you cannot create complex libraries, as the library file including other files would have to know its position relative to the file that included it. This is pretty counter-intuitive. Anyway, even if I go with the fact that the basedir is set in such a way, the output of the above setup is very interesting: NAnt version 0.8.4.0 Copyright (C) 2001-2003 Gerry Shawhttp://nant.sourceforge.net Buildfile: file:///C:/default.build [echo] Including file included.build [echo] Master include included. [echo] Including file task1 [echo] task1 included [echo] Including file task2 BUILD FAILED C:\inc\included.build(7,3):Could not include build file C:\task2.build.Could not find file "C:\task2.build". Total time: 0.1 seconds. The file 'included.build' successfully includes the first file (task1), but fails to include the second one, although they are both specified relative to it. If youwill befixing this issue, I vote that include task keeps it's base relative to the file itself, so that the above described scenario works correctly. For the rest of targets, I guess it is more convenient to inherit the basedir of the including file. Damir p.s. I used v0.8.4.31128. include.zip Description: Zip compressed data
RE: [nant-dev] MSBuild
MSBuild is obviously a child of Embrace Extend philosophy; being built-in in the next version of the framework will do wonders in terms of promoting the process of automated builds, which are critical to quality in our line of work. That is a good thing. Nant is already doing it. And that is even better thing. This tool won't be in place for another year or so, and we have builds to run every night. And even when it comes, it won't do too much for our projects running on 1.0/1.1 framework. We've recently set up a new build environment based on nant and are building 5 large projects with it (one of the projects is a fairly complex consumer app with some 12 variants), and I'm quite happy with it. My point is that we shouldn't spend too much time on discussing MSBuild now -- it's too early. Rather, let's try to make Nant work really, really good right now. It's already useful in this form, and with the great effort that the guys working on it are putting in, I'm confident nant will be successful for a long time, even in the longhorn era. I'd like to see this discussion steer towards defining more focused process to bring version 1.0 out. What are the next steps, how can we contribute in terms of testing, building a library of build scripts, documentation, making the cvs tree being up to date, etc. Gerry co., please keep up the good work. Damir --- 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
