RE: [nant-dev] trycatch task ?... discussion of task communication
How about this stuff? > I think that XML-based communication between tasks and the > trycatch task have different purposes. Specifically, > trycatch is a flow control device. Flow control can > certainly be reproduced with increased task verbosity, but > using a flow control device to describe flow conveys much > more intent, which makes build files (IMHO) easier to read... > or rather, easier to interpret correctly. Hmm. I think inter-task communication could be used for flow control as well. But no problem with trycatch task :) Currently there is resultproperty of task as only way to get result from any task (except of onfailure but it is not very useful on large build scripts). I think this should be enhanced to be able to read stdoutput/stderr for execed program and even more - number of compiled projects from etc. I hope something like this will get in 1.0 timeframe Martin --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] trycatch task ?... discussion of task communication
Hi, * Troy Laurin wrote on 13.07.2004 (09:24): > Sascha Andres wrote: Added above line. Deleted too much, and don't wanted to use undo after I wrote all of the text ;) > > can be accessed from all tasks. The last function adds a protected > > object to the store only readable from a task of the same type. The > > protected Load operations would work analog to this. > > The idea of protected data items sounds interesting, but could it be > implemented without extending Project, just through static properties in > the task class? What do public data items offer that can't be done with > properties? Would it be better (or is it equivalent?) to implement > references, similar to Ant? Just short, cause I'm on my way to work: I think there should be a difference between public data and properties. Public data would be part of the communication, the other is generally part of the build file, used to control how the build is done. The risk overwriting a user property and what may result (broken build, hard build file debugging) led me to propose public data seperated from properties. > > A few words to persistence. Imagine two more overloads, that indicate > > using a boolean variable if an object should be persistent. When a > > data store property on the project is set, a datastore with all > > variables marked persistent will be saved to the given file (and > > loaded at the beginning of the next run). > > Just a comment on overloads: They're generally evil. If two methods do > different things, they should have different names. Compile errors are > preferable to strange program behaviour if you call a method > incorrectly. I agreee that there is potential for wrong calls. I don't have a problem splitting it into Save, SaveProtected, SavePersistent and the respective Load methods. Perhaps something like Protected.Save Public.Save Persistent.Save > Whether storing xml or storing objects, I'm a little wary about the idea > of adding "magic" communication to a build system. It feels too much > like accessing the internal API of a system. If one task relies on the > output of another task to be in a particular format, then there's > usually a good chance that the task will break if the other task changes > its output format. You're right on this point. But using a tasks output is a risk. And changing a tasks output should occur only in beta and / or a major release change. A communication system would be most helpful when there is a large number of user defined tasks - where you could use public and/or protected information. The magic may be useful for debugging issues (a crash in the csc task that occurs only from time to time). -sa -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] trycatch task ?... discussion of task communication
Comments inline... -T > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sascha Andres > > When I think a bit more of sharing information throughout tasks I come > to these points: > > In a programming language, data can be: > > * private > * public > * protected > * static > > and with a bit more work > > * persistent > > IMO there is no situation where I can think of a need for 'declaring' > something static in NAnt if there would be task communication[1]. > Correct me if you can imagine. > > How about introducing a 'DataStore' that is working comparable to the > properties: > > this.Project.DataStore.Save(object); > this.Project.DataStore.Save(name, object); > this.Project.DataStore.Save(name, object, type); > > First function would be the magic variable. If set in a task, this > value remains. If not set, the output of the task could be written to > this special variable. So a load operation always refers to the task > running before. > > Second function would lay an object in the data store with a key so it > can be accessed from all tasks. The last function adds a protected > object to the store only readable from a task of the same type. The > protected Load operations would work analog to this. The idea of protected data items sounds interesting, but could it be implemented without extending Project, just through static properties in the task class? What do public data items offer that can't be done with properties? Would it be better (or is it equivalent?) to implement references, similar to Ant? > A few words to persistence. Imagine two more overloads, that indicate > using a boolean variable if an object should be persistent. When a > data store property on the project is set, a datastore with all > variables marked persistent will be saved to the given file (and > loaded at the beginning of the next run). Just a comment on overloads: They're generally evil. If two methods do different things, they should have different names. Compile errors are preferable to strange program behaviour if you call a method incorrectly. > [From a previous post] > I don't like the we-do-anything-in-xml approach. XML is a nice thing, > but it certainly adds some overhead to communications. > I would prefer an invisible property system based on keys. This would > allow to store informations in one task and to read it in another one, > without dealing with properties set by the user. Whether storing xml or storing objects, I'm a little wary about the idea of adding "magic" communication to a build system. It feels too much like accessing the internal API of a system. If one task relies on the output of another task to be in a particular format, then there's usually a good chance that the task will break if the other task changes its output format. -T Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] trycatch task ?
Clayton, Comments inline... -T > -Original Message- > From: Clayton Harbour [mailto:[EMAIL PROTECTED] > > For instance how would this be handled: > > > > > > > > > > > > > > > > Would it fail the build in the catch or fail the build and still > execute the finally call? If based on the behaviour of C#, the finally call will always be run; the exception/failure that occurred in the try block will be overridden by the failure in the catch block - the actual message displayed as to reason for build failure. Actually, after this point, I personally would diverge from C# handling... in C#, if an exception is thrown from a finally block, it overrides everything (return or throw) from its corresponding try and catch blocks, which can be very misleading when interpreting errors... My approach is to log the finally exception, and continue with the previous operation (be it return or throw).Then again, while acceptible to myself, this divergent behaviour might confuse or mislead other people, so I leave it to the community to decide what the best behaviour might be :-) > Also would we catch specific > exceptions (i.e. exception="IOException"/>) or just have a blanket catch? I had assumed that we were only dealing with BuildException (That's my Java heritage, expecting exceptions to be explicitly declared...). Being able to catch different types of exception and handle them differently might be useful, I'm not sure if it's worth the complexity it could add to build files. One example of this that I can think of: sending a mail to notify of build success... if a socket exception is thrown trying to send the mail, then try the backup mail server... if another socket exception is thrown by the backup mail server, then save the contents of the email to a file. Any other exception would cause a build failure, or at least that notification doesn't happen. (Build failure in notification always feels messy. Build succeeded + notification failed == Build failed...?) One thing that the ant try-catch does that would probably be useful is the ability to reference the exception in the build file. This combined with a function to access a property of a referenced object means you could report intelligent and useful messages if an exception was caught. Typically this would be used to get at the exception message, but for example a compile exception might include a property detailing the files which failed to compile. I don't know if this is the direction NAnt was heading, though. Comments are appreciated. > Probably just details to work out and document, not a "pandora's box" > of complexity :-). One thing that has changed my position is it would > give the build meister a finer grained control of where the build goes > @ each failure...which may or may not be a "bad" thing ;-), and is > something that it sounds like people need. Like most useful features, it can be abused or used incorrectly :-) Good documentation helps prevent the latter... nothing can help prevent the former! Regards, -- Troy Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] trycatch task ?
Hi,
In previous posts on this I was against a (or
:-)) task. I have had time to rethink this position though, and
although I think it will make build scripts a little more complex (or a
lot depending how fancy you get) it would definitely be useful. In my
opinion I would find it easier to keep track of if the task wrapped the
conditional (or potential failure I guess...depending how you think of
it), rather than perform an operation and evaluate the error (i.e. the
errorproperty attribute), but it does bring up some interesting
scenarios. For instance how would this be handled:
Would it fail the build in the catch or fail the build and still execute
the finally call? Also would we catch specific exceptions (i.e. ) or just have a blanket catch? Probably just
details to work out and document, not a "pandora's box" of complexity
:-). One thing that has changed my position is it would give the build
meister a finer grained control of where the build goes @ each
failure...which may or may not be a "bad" thing ;-), and is something
that it sounds like people need.
So I guess it is time to summarize :-).
+1 for the (or )
Cheers,
Clayton
> -Original Message-
> From: Gert Driesen [mailto:[EMAIL PROTECTED]
> Sent: July 8, 2004 11:05 PM
> To: Troy Laurin; Nant-Developers (E-Mail)
> Subject: Re: [nant-dev] trycatch task ?
>
>
> Troy,
>
> I think we first need to come to an agreement on whether its
> a good idea to add a try-catch task, or whether to go for the
> errorproperty implementation.
>
> I don't think it's a good idea to implement both.
>
> Your task implementation is a bit limited, the ant-contrib
> task is more powerful. I think it would be best to compare
> the ant-contrib task with the errorproperty proposal :
>
> errorproperty implementation :
>
>
> unless="${buildfailure}" />
> unless="${buildfailure}" />
>
>
>
> trycatch implementation :
>
>
>
>
>
>
>
>
>
>
>
> I think I'd prefer the (or ) task, but
> I could be convinced otherwise ;-)
>
> Gert
>
> - Original Message -
> From: "Troy Laurin" <[EMAIL PROTECTED]>
> To: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
> Sent: Friday, July 09, 2004 4:06 AM
> Subject: RE: [nant-dev] trycatch task ?
>
>
> I'm not sure about a try-catch task, but I found that a
> try-finally task (attached... the implementation is the
> obvious one, which seems to work) greatly improved the
> apparent intent of my build file for a clearcase-export
> target (Needed only because clearcase doesn't actually
> support the idea of 'export', but that's getting
> off-track...) It would be trivial to add a catch block to
> this if necessary.
>
> I don't have any unit tests for this at the moment, but I can
> knock up a test suite and send that on next week, if you want
> the task.
>
>
> Just a comment on the need for a catch block, and discussion
> of an alternative... Would addition of the trycatch task
> preclude the need to implement the RFE for 'errorproperty' in
> tasks? (Ref
> http://sourceforge.net/tracker/index.php?func=detail&aid=85319
> 8&group_id
> =31650&atid=402871, or http://tinyurl.com/2h69t) Or vice
> versa? Using trycatch to simulate errorproperty is probably
> more verbose in the project file, particularly on a single
> task, but is debatably more expressive, particularly on a
> related set of tasks.
>
> If only one of trycatch or errorproperty were implemented,
> you could basically guarantee that some (many?) people would
> use it to simulate the other... if both were implemented, is
> it a good or a bad thing that there would be two (roughly
> equally appropriate) ways of doing the same thing?
>
>
> Compare:
>
>
> unless="${buildfailure}" />
> unless="${buildfailure}" />
>
>
>
> with:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The first is easier to extend with different properties for
> failures in different parts of the build/test process. The
> second is possibly easier to read. In terms of
> performance/correctness, they both perform essentially the
> same set of functional instructions, so
> performance/correctness should be the same.
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> Behalf Of Gert
> > Driesen
> > Sent: F
Re: [nant-dev] trycatch task ?... discussion of task communication
Hi, * Martin Aliger wrote on 09.07.2004 (13:43): > to pass information from one task to other. Since speed is not main interest > in automated builds (sorry Matt - I still appreciate your optimization > work!) XML should be straightforward solution. But I never think we will > serialize XML on every task. XML hierarchy is pretty efficiently stored in > memory like object tree and that should be enough (what is exactly what you > propose, isn't it?) Task communication is no more than sharing information in the mean of a variable all tasks can read (or a memory location with XML or what-ever in it). When I think a bit more of sharing information throughout tasks I come to these points: In a programming language, data can be: * private * public * protected * static and with a bit more work * persistent IMO there is no situation where I can think of a need for 'declaring' something static in NAnt if there would be task communication[1]. Correct me if you can imagine. IMHO private data is always task-instance specific and doesn't need to be tracked by a NAnt wide communication system. Public data can be shared with other tasks without restrictions. Protected data can only be accessed by tasks of the same type (like my stopwatch task). I'll focus on persistent data later. How about introducing a 'DataStore' that is working comparable to the properties: this.Project.DataStore.Save(object); this.Project.DataStore.Save(name, object); this.Project.DataStore.Save(name, object, type); First function would be the magic variable. If set in a task, this value remains. If not set, the output of the task could be written to this special variable. So a load operation always refers to the task running before. Second function would lay an object in the data store with a key so it can be accessed from all tasks. The last function adds a protected object to the store only readable from a task of the same type. The protected Load operations would work analog to this. A few words to persistence. Imagine two more overloads, that indicate using a boolean variable if an object should be persistent. When a data store property on the project is set, a datastore with all variables marked persistent will be saved to the given file (and loaded at the beginning of the next run). Personally I would restrict the use of persistent data to objects that are serializable for the sake of easy save and restore. In a first version I would try a datastore based on hashtables. But that's a step further. And after a second thought there are some things certainly coming up if task communication is possible: * How can I list all key / value combinations in the datastore? * Can there be persitence over the bounds of a buildfile? * Can I persist data only accessible to one specific task-instance? The persistence feature is certainly very interesting, but would definitly lead to much more possible complexity in both the build files and the tasks. This should be taken into account. Nevertheless I would call me a supporter for the idea of communication as it would have been great if I could have used this in my own version task and probably the stopwatch task. And to close the run with XML: If a task lays XML to the store or not would be up to the tasks author. In some cases this is a nice, straightforward way to organize information, in others not. Who cares if you can use the store for all kind of objects? -sa [1] This is IMHO true as long as NAnt doesn't use a high level language to write buildfiles ;) -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] trycatch task ?... discussion of task communication
Hi again, > > Some time ago I propose XML-like based communication - maybe its time comes? > > How do you see it now when there was enough time to consider it? > > I don't like the we-do-anything-in-xml approach. XML is a > nice thing, but it certainly adds some overhead to > communications. I would prefer an invisible property system > based on keys. This would allow to store informations in one > task and to read it in another one, without dealing with > properties set by the user. I'm in no way "xml guy". XML is nice thing for some purpose but definitely not usable for everything. What I propose is to introduce _some_ system how to pass information from one task to other. Since speed is not main interest in automated builds (sorry Matt - I still appreciate your optimization work!) XML should be straightforward solution. But I never think we will serialize XML on every task. XML hierarchy is pretty efficiently stored in memory like object tree and that should be enough (what is exactly what you propose, isn't it?) --- >Perhaps the problem is just that I can't think of an example for which >verbose inter-task communication would be a good fit. Do you have an >example that is more extensive than the exec example that you can share? More complex example? Ok here is one from mine real needs: I have without .sln file but I include fileset of . But compilation itself is only small part of every complex build. I need to check,sign,ftp,copy,... builded assemblies. If one of those assemblies failed to compile, whole failed and now I'm forced to scan directory what is builded to know what I have to process further. And I'm totally short to make some meaningful error log in such case. If have ability to construct some result block I could parse it and construct result-fileset as well as error-log and whatever information I need. E.g. (in xml syntax) it could return: Having that one could easily condition other tasks with +. --- >dependencies... but in practice, if a particular task is so dependent on >the output of another task, then why doesn't it extend (or compose) the >other task. This allows the task to communicate with its predecessor in >the trivial way, through object properties and method calls, without >having to modify how NAnt works. True. But why contruct some task for everything? This is case of or even (which calls ) and it is ok. I do not want to call every task myself - solution is great! On the other hand I do not want to write task for every one time stuff. Regards, Martin --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] trycatch task ?
Hi, * Martin Aliger wrote on 09.07.2004 (08:40): > I think both are cases of inter-task communication. IMO current nant is > totally missing such communication. errorproperty proposal is very limited > implementation of such communication. I'd rather prefer making something > more robust enabling more advanced scenarios like examining what failed or > what was skipped (mainly in complex tasks like ) etc. Well, there is a workaround: I wrote a stopwatch task (I wanted to know time some tasks are taking). The user must give a name. Based on this name I create a property that I used to save the current timestamp. If not empty, I compare the current timestamp to the saved one (hopefully in the property). The bad in this approach is (IMHO), that the property becomes 'visible' to the outer world in the script. This is not always intended. > Some time ago I propose XML-like based communication - maybe its time comes? > How do you see it now when there was enough time to consider it? I don't like the we-do-anything-in-xml approach. XML is a nice thing, but it certainly adds some overhead to communications. I would prefer an invisible property system based on keys. This would allow to store informations in one task and to read it in another one, without dealing with properties set by the user. I could also imagine a way of making them optionally persistent. This would be a way to provide numerous version tasks a clear way to save / load information from one run to the next without 'proprietary' file formats. > task is also good addition in mine eyes. I personally dont see > anything bad in implementing both - trycatch and some kinf of communication > in the same time. Different scenarios should use different approaches A try catch task can help to make things more clear. I like the idea that something like that arises. -sa -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] trycatch task ?... discussion of task communication
Martin, just read through your previous thread. I think that XML-based communication between tasks and the trycatch task have different purposes. Specifically, trycatch is a flow control device. Flow control can certainly be reproduced with increased task verbosity, but using a flow control device to describe flow conveys much more intent, which makes build files (IMHO) easier to read... or rather, easier to interpret correctly. I'm not sure how much I agree with xml output for tasks. I can see how it would be useful in theory for chaining together tasks with strong dependencies... but in practice, if a particular task is so dependent on the output of another task, then why doesn't it extend (or compose) the other task. This allows the task to communicate with its predecessor in the trivial way, through object properties and method calls, without having to modify how NAnt works. The best example I have of this concept is the solution task. All of the tools and tasks (more or less) required to simulate the solution task are available... they could be extended with verbose outputs to allow chaining them together, but it is much more useful as a single task, which composes its required tasks and facilitates communication between the tasks. Perhaps the problem is just that I can't think of an example for which verbose inter-task communication would be a good fit. Do you have an example that is more extensive than the exec example that you can share? Regards, -- Troy > -Original Message- > From: Martin Aliger [mailto:[EMAIL PROTECTED] > Sent: Friday, 9 July 2004 2:40 PM > To: Gert Driesen; Troy Laurin; Nant-Developers (E-Mail) > Subject: Re: [nant-dev] trycatch task ? > > I think both are cases of inter-task communication. IMO > current nant is totally missing such communication. > errorproperty proposal is very limited implementation of such > communication. I'd rather prefer making something more robust > enabling more advanced scenarios like examining what failed > or what was skipped (mainly in complex tasks like ) etc. > > Some time ago I propose XML-like based communication - maybe > its time comes? > How do you see it now when there was enough time to consider it? > > task is also good addition in mine eyes. I > personally dont see anything bad in implementing both - > trycatch and some kinf of communication in the same time. > Different scenarios should use different approaches > > Regards, > Martin Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] trycatch task ?
Gert,
My implementation of the task is extremely limited, but it exactly fits
our requirements :-) It would need to be reworked to fit the broader
requirements of the community before being released, of course.
Notwithstanding, you are right in that the task shouldn't be just
dropped in without examining if it is the appropriate choice. For what
it's worth, I still feel that trycatch is the more expressive option,
plus it is slightly more structured and less prone to cut'n'paste
error... its only real downside is being (slightly?) more verbose than
using errorproperty, leading to larger build files.
-T
> -Original Message-
> From: Gert Driesen [mailto:[EMAIL PROTECTED]
> Sent: Friday, 9 July 2004 2:05 PM
> To: Troy Laurin; Nant-Developers (E-Mail)
> Subject: Re: [nant-dev] trycatch task ?
>
> Troy,
>
> I think we first need to come to an agreement on whether its
> a good idea to add a try-catch task, or whether to go for the
> errorproperty implementation.
>
> I don't think it's a good idea to implement both.
>
> Your task implementation is a bit limited, the ant-contrib
> task is more powerful. I think it would be best to compare
> the ant-contrib task with the errorproperty proposal :
>
> errorproperty implementation :
>
>
> unless="${buildfailure}" />
> unless="${buildfailure}" />
>
>
>
> trycatch implementation :
>
>
>
>
>
>
>
>
>
>
>
> I think I'd prefer the (or ) task, but
> I could be convinced otherwise ;-)
>
> Gert
>
> ----- Original Message -
> From: "Troy Laurin" <[EMAIL PROTECTED]>
> To: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
> Sent: Friday, July 09, 2004 4:06 AM
> Subject: RE: [nant-dev] trycatch task ?
>
>
> I'm not sure about a try-catch task, but I found that a
> try-finally task (attached... the implementation is the
> obvious one, which seems to work) greatly improved the
> apparent intent of my build file for a clearcase-export
> target (Needed only because clearcase doesn't actually
> support the idea of 'export', but that's getting
> off-track...) It would be trivial to add a catch block to
> this if necessary.
>
> I don't have any unit tests for this at the moment, but I can
> knock up a test suite and send that on next week, if you want
> the task.
>
>
> Just a comment on the need for a catch block, and discussion
> of an alternative... Would addition of the trycatch task
> preclude the need to implement the RFE for 'errorproperty' in
> tasks? (Ref
> http://sourceforge.net/tracker/index.php?func=detail&aid=85319
> 8&group_id
> =31650&atid=402871, or http://tinyurl.com/2h69t) Or vice versa?
> Using trycatch to simulate errorproperty is probably more
> verbose in the project file, particularly on a single task,
> but is debatably more expressive, particularly on a related
> set of tasks.
>
> If only one of trycatch or errorproperty were implemented,
> you could basically guarantee that some (many?) people would
> use it to simulate the other... if both were implemented, is
> it a good or a bad thing that there would be two (roughly
> equally appropriate) ways of doing the same thing?
>
>
> Compare:
> failonerror="false" errorproperty="buildfailure" />
> unless="${buildfailure}" />
> unless="${buildfailure}" />
>
>
>
> with:
>
>
>
>
>
>
>
>
> />
>
>
>
>
> The first is easier to extend with different properties for
> failures in different parts of the build/test process. The
> second is possibly easier to read. In terms of
> performance/correctness, they both perform essentially the
> same set of functional instructions, so
> performance/correctness should be the same.
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> Behalf Of Gert
> > Driesen
> > Sent: Friday, 9 July 2004 2:48 AM
> > To: Nant-Developers (E-Mail)
> > Subject: [nant-dev] trycatch task ?
> >
> > Hi,
> >
> > I wonder if we should ask a task to
> NAnt(Contrib), similar
> > to what AntContrib has :
> > http://ant-contrib.sourceforge.net/tasks/trycatch.html
> >
> > Can anybody come up with a better alternative ?
> >
> > Gert
>
>
> Disclaimer Message:
>
> This message contains confidential information and is
> intended only fo
Re: [nant-dev] trycatch task ?
I think both are cases of inter-task communication. IMO current nant is
totally missing such communication. errorproperty proposal is very limited
implementation of such communication. I'd rather prefer making something
more robust enabling more advanced scenarios like examining what failed or
what was skipped (mainly in complex tasks like ) etc.
Some time ago I propose XML-like based communication - maybe its time comes?
How do you see it now when there was enough time to consider it?
task is also good addition in mine eyes. I personally dont see
anything bad in implementing both - trycatch and some kinf of communication
in the same time. Different scenarios should use different approaches
Regards,
Martin
- Original Message -
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "Troy Laurin" <[EMAIL PROTECTED]>; "Nant-Developers
(E-Mail)" <[EMAIL PROTECTED]>
Sent: Friday, July 09, 2004 8:04 AM
Subject: Re: [nant-dev] trycatch task ?
> Troy,
>
> I think we first need to come to an agreement on whether its a good idea
to
> add a try-catch task, or whether to go for the errorproperty
implementation.
>
> I don't think it's a good idea to implement both.
>
> Your task implementation is a bit limited, the ant-contrib task is more
> powerful. I think it would be best to compare the ant-contrib
> task with the errorproperty proposal :
>
> errorproperty implementation :
>
>
> unless="${buildfailure}" />
> unless="${buildfailure}" />
>
>
>
>
> trycatch implementation :
>
>
>
>
>
>
>
>
>
>
>
>
> I think I'd prefer the (or ) task, but I could be
> convinced otherwise ;-)
>
> Gert
>
> - Original Message -
> From: "Troy Laurin" <[EMAIL PROTECTED]>
> To: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
> Sent: Friday, July 09, 2004 4:06 AM
> Subject: RE: [nant-dev] trycatch task ?
>
>
> I'm not sure about a try-catch task, but I found that a try-finally task
> (attached... the implementation is the obvious one, which seems to work)
> greatly improved the apparent intent of my build file for a
> clearcase-export target (Needed only because clearcase doesn't actually
> support the idea of 'export', but that's getting off-track...) It would
> be trivial to add a catch block to this if necessary.
>
> I don't have any unit tests for this at the moment, but I can knock up a
> test suite and send that on next week, if you want the task.
>
>
> Just a comment on the need for a catch block, and discussion of an
> alternative... Would addition of the trycatch task preclude the need to
> implement the RFE for 'errorproperty' in tasks? (Ref
> http://sourceforge.net/tracker/index.php?func=detail&aid=853198&group_id
> =31650&atid=402871, or http://tinyurl.com/2h69t) Or vice versa?
> Using trycatch to simulate errorproperty is probably more verbose in the
> project file, particularly on a single task, but is debatably more
> expressive, particularly on a related set of tasks.
>
> If only one of trycatch or errorproperty were implemented, you could
> basically guarantee that some (many?) people would use it to simulate
> the other... if both were implemented, is it a good or a bad thing that
> there would be two (roughly equally appropriate) ways of doing the same
> thing?
>
>
> Compare:
>
>
> unless="${buildfailure}" />
> unless="${buildfailure}" />
>
>
>
>
> with:
>
>
>
>
>
>
>
>
>
> />
>
>
>
>
> The first is easier to extend with different properties for failures in
> different parts of the build/test process. The second is possibly
> easier to read. In terms of performance/correctness, they both perform
> essentially the same set of functional instructions, so
> performance/correctness should be the same.
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Gert Driesen
> > Sent: Friday, 9 July 2004 2:48 AM
> > To: Nant-Developers (E-Mail)
> > Subject: [nant-dev] trycatch task ?
> >
> > Hi,
> >
> > I wonder if we should ask a task to NAnt(Contrib),
> > similar to what AntContrib has :
> > http://ant-contrib.sourceforge.net/tasks/trycatch.html
> >
> > Can anybody come up with a better alternative ?
> >
> > Gert
>
>
> Disclaimer Message:
>
> This message contains confidential information and is intended only for
the
> i
Re: [nant-dev] trycatch task ?
Troy, I think we first need to come to an agreement on whether its a good idea to add a try-catch task, or whether to go for the errorproperty implementation. I don't think it's a good idea to implement both. Your task implementation is a bit limited, the ant-contrib task is more powerful. I think it would be best to compare the ant-contrib task with the errorproperty proposal : errorproperty implementation : trycatch implementation : I think I'd prefer the (or ) task, but I could be convinced otherwise ;-) Gert - Original Message - From: "Troy Laurin" <[EMAIL PROTECTED]> To: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Friday, July 09, 2004 4:06 AM Subject: RE: [nant-dev] trycatch task ? I'm not sure about a try-catch task, but I found that a try-finally task (attached... the implementation is the obvious one, which seems to work) greatly improved the apparent intent of my build file for a clearcase-export target (Needed only because clearcase doesn't actually support the idea of 'export', but that's getting off-track...) It would be trivial to add a catch block to this if necessary. I don't have any unit tests for this at the moment, but I can knock up a test suite and send that on next week, if you want the task. Just a comment on the need for a catch block, and discussion of an alternative... Would addition of the trycatch task preclude the need to implement the RFE for 'errorproperty' in tasks? (Ref http://sourceforge.net/tracker/index.php?func=detail&aid=853198&group_id =31650&atid=402871, or http://tinyurl.com/2h69t) Or vice versa? Using trycatch to simulate errorproperty is probably more verbose in the project file, particularly on a single task, but is debatably more expressive, particularly on a related set of tasks. If only one of trycatch or errorproperty were implemented, you could basically guarantee that some (many?) people would use it to simulate the other... if both were implemented, is it a good or a bad thing that there would be two (roughly equally appropriate) ways of doing the same thing? Compare: with: The first is easier to extend with different properties for failures in different parts of the build/test process. The second is possibly easier to read. In terms of performance/correctness, they both perform essentially the same set of functional instructions, so performance/correctness should be the same. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Gert Driesen > Sent: Friday, 9 July 2004 2:48 AM > To: Nant-Developers (E-Mail) > Subject: [nant-dev] trycatch task ? > > Hi, > > I wonder if we should ask a task to NAnt(Contrib), > similar to what AntContrib has : > http://ant-contrib.sourceforge.net/tasks/trycatch.html > > Can anybody come up with a better alternative ? > > Gert Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] trycatch task ?
I'm not sure about a try-catch task, but I found that a try-finally task (attached... the implementation is the obvious one, which seems to work) greatly improved the apparent intent of my build file for a clearcase-export target (Needed only because clearcase doesn't actually support the idea of 'export', but that's getting off-track...) It would be trivial to add a catch block to this if necessary. I don't have any unit tests for this at the moment, but I can knock up a test suite and send that on next week, if you want the task. Just a comment on the need for a catch block, and discussion of an alternative... Would addition of the trycatch task preclude the need to implement the RFE for 'errorproperty' in tasks? (Ref http://sourceforge.net/tracker/index.php?func=detail&aid=853198&group_id =31650&atid=402871, or http://tinyurl.com/2h69t) Or vice versa? Using trycatch to simulate errorproperty is probably more verbose in the project file, particularly on a single task, but is debatably more expressive, particularly on a related set of tasks. If only one of trycatch or errorproperty were implemented, you could basically guarantee that some (many?) people would use it to simulate the other... if both were implemented, is it a good or a bad thing that there would be two (roughly equally appropriate) ways of doing the same thing? Compare: with: The first is easier to extend with different properties for failures in different parts of the build/test process. The second is possibly easier to read. In terms of performance/correctness, they both perform essentially the same set of functional instructions, so performance/correctness should be the same. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Gert Driesen > Sent: Friday, 9 July 2004 2:48 AM > To: Nant-Developers (E-Mail) > Subject: [nant-dev] trycatch task ? > > Hi, > > I wonder if we should ask a task to NAnt(Contrib), > similar to what AntContrib has : > http://ant-contrib.sourceforge.net/tasks/trycatch.html > > Can anybody come up with a better alternative ? > > Gert Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. TryFinallyTask.cs Description: TryFinallyTask.cs
[nant-dev] trycatch task ?
Hi, I wonder if we should ask a task to NAnt(Contrib), similar to what AntContrib has : http://ant-contrib.sourceforge.net/tasks/trycatch.html Can anybody come up with a better alternative ? Gert --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
