Re: [nant-dev] 2 small changes to consider
Hello 1) Multiple files: Added a project level variable called nant.project.failure, such that a you can allow a task or group of tasks to complete regardless of failure using failonerror=false, and then afterwards check the value of nant.project.failure to determine if a failure occurred. Very useful for batch nunit tests, and gathering a report of the tests before checking if a failure occurred and throwing a fail. This points out a gap in nant as I see it. What Jeff has made a patch for is actually a pretty large gap in functionality in nant. Controlling the flow using failure detection and also log that neatly for other tools to pick up (CCNet comes to mind) is challenging to say the least. Agree. And one global property is not general solution. It is just the flag - it didnt say why it failed, how many tasks failed, etc. The same matter I tried to solve with inter-task communication I presented some time ago. So you could give task failonerror=false and then check resulting output from task what is done, what fails etc etc. trycatch task is another possibility. Maybe they could exists both and catch block could get output from failed task to examine why it fails. Regards, Martin --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] 2 small changes to consider
Our group approached this problem by adding capability to the nant task that allowed a nested nant call to set values for properties that were then available to the calling client. When tests fail for some project, we add the name of the project to the property, which then gets displayed at the end of the build, such as: Tests failed in projects: x, y. or Built projects: a, b, c. Randy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Aliger Sent: Friday, February 27, 2004 9:20 AM To: Nicklas Norling; 'Gert Driesen'; [EMAIL PROTECTED] Subject: Re: [nant-dev] 2 small changes to consider Hello 1) Multiple files: Added a project level variable called nant.project.failure, such that a you can allow a task or group of tasks to complete regardless of failure using failonerror=false, and then afterwards check the value of nant.project.failure to determine if a failure occurred. Very useful for batch nunit tests, and gathering a report of the tests before checking if a failure occurred and throwing a fail. This points out a gap in nant as I see it. What Jeff has made a patch for is actually a pretty large gap in functionality in nant. Controlling the flow using failure detection and also log that neatly for other tools to pick up (CCNet comes to mind) is challenging to say the least. Agree. And one global property is not general solution. It is just the flag - it didnt say why it failed, how many tasks failed, etc. The same matter I tried to solve with inter-task communication I presented some time ago. So you could give task failonerror=false and then check resulting output from task what is done, what fails etc etc. trycatch task is another possibility. Maybe they could exists both and catch block could get output from failed task to examine why it fails. Regards, Martin --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] 2 small changes to consider
Hi, I think reporting on which targets/projects passed and failed would be a great idea, maybe with an indication of whether this failure is alright as defined by the build script. I am not so keen on adding try/catch blocks to build files though. In my mind attempting to catch and recover from a build failure during a build just seems like it could get way to messy and in my mind would add some uncertainty about the results. I think it would be better to keep it as close to a pass/fail outcome as possible and just provide enough information about what failed and why to help the local build meister fix it for next time. Clayton -Original Message- From: Randy Regnier [mailto:[EMAIL PROTECTED] Sent: February 27, 2004 7:42 AM To: 'Martin Aliger'; 'Nicklas Norling'; 'Gert Driesen'; [EMAIL PROTECTED] Subject: RE: [nant-dev] 2 small changes to consider Our group approached this problem by adding capability to the nant task that allowed a nested nant call to set values for properties that were then available to the calling client. When tests fail for some project, we add the name of the project to the property, which then gets displayed at the end of the build, such as: Tests failed in projects: x, y. or Built projects: a, b, c. Randy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Aliger Sent: Friday, February 27, 2004 9:20 AM To: Nicklas Norling; 'Gert Driesen'; [EMAIL PROTECTED] Subject: Re: [nant-dev] 2 small changes to consider Hello 1) Multiple files: Added a project level variable called nant.project.failure, such that a you can allow a task or group of tasks to complete regardless of failure using failonerror=false, and then afterwards check the value of nant.project.failure to determine if a failure occurred. Very useful for batch nunit tests, and gathering a report of the tests before checking if a failure occurred and throwing a fail. This points out a gap in nant as I see it. What Jeff has made a patch for is actually a pretty large gap in functionality in nant. Controlling the flow using failure detection and also log that neatly for other tools to pick up (CCNet comes to mind) is challenging to say the least. Agree. And one global property is not general solution. It is just the flag - it didnt say why it failed, how many tasks failed, etc. The same matter I tried to solve with inter-task communication I presented some time ago. So you could give task failonerror=false and then check resulting output from task what is done, what fails etc etc. trycatch task is another possibility. Maybe they could exists both and catch block could get output from failed task to examine why it fails. Regards, Martin --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438 op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438 op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
This patch adds wildcard support to file::exists(). Basically it uses DirectoryScanner to find matching files. Is it ok to commit it ? Jarek fileexists.patch Description: Binary data
Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
Speed? Of course it's possible to always use the scanner and I can change
it.
Jarek
- Original Message -
From: Scott Hernandez [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]; Hemry, Jeff
[EMAIL PROTECTED]
Cc: ! nant [EMAIL PROTECTED]
Sent: Friday, February 27, 2004 8:27 PM
Subject: Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
small changes to consider
Is there any reason that you don't always use the scanner?
if (file.IndexOf(*) != -1 || file.IndexOf(?) != -1) {
...
} else
return File.Exists(Project.GetFullPath(file));
Less code paths, etc... :)
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Hemry, Jeff [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, February 27, 2004 11:13 AM
Subject: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
small
changes to consider
This patch adds wildcard support to file::exists(). Basically it uses
DirectoryScanner to find matching files.
Is it ok to commit it ?
Jarek
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
Yeah, I'm sure we all go back and forward on this issue. Performance is important, and we should strive towards it, but I have found that sometimes what seems like a performance tweak turns out to not work out as I expect. I'm sure the scanner is slower than file.exists, but in this case I would lean towards less code paths, and leave the performance issues till we start to see a problem. Profiling nant will most likely result in all kinds of hot spots. If this is an issue, changing it will be important. It may even be that we tune the scanner to check for the special case of a file without any wildcards, then the overhead is just a few objects and a virtual method calls, as compared to just the file.exists call. I'm sure the slowest part of all this, by far, is the io operation to check for the file. This is really more of a general question as to whether we should code for less code paths (simpler code?) or try to write with performance in mind. I'm leaning towards less code paths... :) It's fine with me, really ;-) Jarek --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] 2 small changes to consider
- Original Message - From: Hemry, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 26, 2004 8:48 PM Subject: [nant-dev] 2 small changes to consider Hi all, Here are 2 small changes put in place for our specific needs that may be beneficial to the whole group. 1) Multiple files: Added a project level variable called nant.project.failure, such that a you can allow a task or group of tasks to complete regardless of failure using failonerror=false, and then afterwards check the value of nant.project.failure to determine if a failure occurred. Very useful for batch nunit tests, and gathering a report of the tests before checking if a failure occurred and throwing a fail. Not sure if we should something like this, but we'll give it some thought ... 2) Availabletask: modified to allow for wildcards, such that it would be acceptable to determine if c:\temp\*.txt is available. I guess you could accomplish this using the foreach task, perhaps not a pretty way to do it, but possible ... We are actually thinking about deprecating the available task as all of its functionality is now also available using expressions/functions ... Gert --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] 2 small changes to consider
2) Availabletask: modified to allow for wildcards, such that it would be acceptable to determine if c:\temp\*.txt is available. I guess you could accomplish this using the foreach task, perhaps not a pretty way to do it, but possible ... We are actually thinking about deprecating the available task as all of its functionality is now also available using expressions/functions ... Or we can extend file::exists() to accept wildcards... Jarek --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
