Re: [nant-dev] nested taskcontainers, tasks, elements or datatypes?
On 9/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[BuildElementArray(jobgroup)]
public JobGroupCollection groups
{
get { return _groups; }
set
{
for( int i = 0; i value.Count; i++ )
{
JobGroup group = value[i];
this.addJobGroup( group );
}
this._groups = value;
}
}
[BuildElementArray(job)]
public JobDefinitionCollection jobs
{
get { return _jobs; }
set
{
String thisMethod = jobs.set;
log.Debug(thisMethod + :entering...);
for( int i = 0; i value.Count; i++ )
{
JobDefinition job = value[i];
this.addJobDefinition( job );
}
_jobs = value;
}
}
}
I notice that in your setter methods, you are calling a function to
individually add the job[group]s to your group, as well as setting the
passed job[group] into your local member. Without seeting your
addJobGroup and addJobDefinition methods, I can't be sure, but it
looks like you're duplicating effort - you are likely to need only one
or the other.
But that shouldn't be causing the problem you describe... Perhaps if
you add more logging (as the log.Debug line to specify that the jobs
setter is being accessed) and run ant with debug output enabled you
may have more insight why your nested jobs aren't being processed.
For a concrete example of a recursive datatype, look at the PathSet
datatype (NAnt.Core\Types\PathSet.cs)... the relevant snippet:
/// summary
/// Defines a set of path elements to add to the current path.
/// /summary
/// param name=pathThe see cref=PathSet / to add./param
[BuildElement(path)]
public void AddPath(PathSet path) {
_elements.Add(path);
}
/// summary
/// Defines a path element to add to the current path.
/// /summary
/// param name=pathElementThe see cref=PathElement /
to add./param
[BuildElement(pathelement)]
public void AddPathElement(PathElement pathElement) {
_elements.Add(pathElement);
}
The major difference (I believe) between using a property setter and
the AddXxx methods is that the AddXxx methods retain order,
particularly when the types are polymorphic and mixed, as in a path
element.
Hope that gives you something to work with,
Regards and good luck,
--
Troy
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42 plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] task decorators/listeners, was Re: [Nant-users] Build target from command line without dependencies
On 9/22/05, Gary Feldman [EMAIL PROTECTED] wrote: Troy Laurin wrote: On 9/20/05, Gary Feldman [EMAIL PROTECTED] wrote: but on the other hand there are some things that make can do easily, but which are tricky or more work to do in NAnt - such as adding a project-wide pre or post compile step. That actually sounds like a good idea... do you think there would be demand for an AOP-style framework for NAnt, so tasks can be extended by registering pre- and post-task event listeners which can inspect the task's parameters and optionally modify those parameters, or trigger some other action? I don't think that AOP has crossed the chasm yet, and the way it violates the principle of locality of reference makes me wonder whether it's appropriate for the typical NAnt user. AOP is certainly still in its infancy and hasn't quite proven that it is here to stay... and you're right that it does violate locality, but it also has the potential to improve the declarative nature of NAnt. Another idea might be to just have a mechanism to set defaults. I think AOP would be much more useful in terms of triggering actions in response to tasks. Almost the inverse of target dependencies - one target specifies that it can't run until this other target has already run... in contrast, a trigger would specify that it must be run before this particular task is run. For an example that's not great (but may grow into something more useful), the standard concept of updating source code before building it could be reimplemented as a pre-trigger on the cpp task - before the source is compiled (or even the up-to-date check), the trigger could update the source files from source control. I stress that the above example isn't a good idea in and of itself - there is very little use in general in updating a small portion of a source tree, and a great danger in updating multiple parts of a source tree in multiple operations. The already standard pattern of updating the entire tree is much more useful in general, and much safer. The example is just the best I could think of at the moment. Perhaps that's a sign that there isn't a valid use-case for this in NAnt? :-) Off topic, what's a typical NAnt user? ;-) Valid point, though. If in practice using AOP is just as likely to obfuscate build files as clarify them then the documentation should clearly state that the facility shouldn't be used unless it is likely to simplify the build script, or if it would be difficult to write the script without. -- Troy --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: [Nant-users] Build target from command line without dependencies
On 9/20/05, Gary Feldman [EMAIL PROTECTED] wrote: but on the other hand there are some things that make can do easily, but which are tricky or more work to do in NAnt - such as adding a project-wide pre or post compile step. That actually sounds like a good idea... do you think there would be demand for an AOP-style framework for NAnt, so tasks can be extended by registering pre- and post-task event listeners which can inspect the task's parameters and optionally modify those parameters, or trigger some other action? I can't think of a useful example off the top of my head, unfortunately. Would anyone else find this useful in some way? -- Troy --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Fwd: Filesets referencing filesets ?
On 8/26/05, Martin Aliger [EMAIL PROTECTED] wrote: Thanks, here is patch again, this time it is agains 0.85 RC3. I'd really love to see this incorporated in core. There are some implementation problems which we already discussed, though: - what should happen, if referenced fileset have another basedir ? - what should happen, if exclude/include of 2 filesets conflicts ? - is every possible combination of those covered in test cases? For mine use, I dont combine basedirs and dont use excludes at all, but those problems should be solved. I feel, this is main problem why this extension wasnt incorporated yet. Maybe we could discuss it now... My take on the matter... I would definitely like the ability to combine filesets, personally... it places less onus on the task creator to add explicit support to reference files in different locations. I think that it is critical to support merging filesets with different basedirs, given this is probably the most requested feature for some tasks, such as the zip task - create a zip including files from different folders... the path to the file from the basedir is very important when determining the retained path in the zip. Regarding includes/excludes conflicts, I think it would make the most sense (ie- least support queries) to offer both: Logical intersection of two filesets - include all files referenced in each fileset, regardless if that file is excluded by the other fileset: fileset include fileset=fileset1/ include fileset=fileset2/ /fileset Logical subtraction of two filesets - include those files in fileset1 that are not in fileset2: fileset include fileset=fileset1/ exclude fileset=fileset2/ /fileset I'm not convinced it makes sense to include logical intersection of two filesets. Regarding determining hits between the contents of filesets for subtraction, I would suggest comparison based on path to the file relative to the containing fileset's basedir... so the file /a/b/c/d with a basedir of /a/b and the file /x/y/z/c/d with a basedir of /x/y/z would have the same relative path. Comments? Do other people's (expected?) usage patterns of filesets match/conflict with the above? -- Troy --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Redirecting exec output to stdout
On 7/15/05, Kevin [EMAIL PROTECTED] wrote: What is the best course of action for getting this implemented? Can I become a contributing developer and do it myself, or is someone else willing to do it? Thank you. - Kevin Dietz Kevin, I spent some time implementing this behaviour last year, but have been waiting for the 0.85 release before getting it patched into the source tree. I'll rustle up the code and make sure it works in the latest version of NAnt, then submit the RFE with patches. You'll be able to patch your local NAnt if you want this behaviour before it is committed into the CVS tree. I should have some time tonight to do this. -- Troy --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] update existing zipfile using zip task
On 7/8/05, McKenna, Simon (RGH) [EMAIL PROTECTED] wrote: For addition or modification of files and directories in an existing zipfile, zip task could have an append boolean attribute, and for deletion of existing files, it could have a delete boolean attribute. append would be mutually exclusive to delete, which should keep the fileset element unchanged. Suggestion: Rather than two attributes with extra validation, use a single attribute (mode?) taking its values from an enumeration, similar to the 'item' attribute of the foreach task. http://nant.sourceforge.net/release/latest/help/tasks/foreach.html That way, your zip task mode could be one of Create (what it does now), Update or Delete... while leaving room for extension without polluting the namespace or logicspace :-) -- Troy --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] How to pass dynamic properties from the command line ?
On 7/5/05, SIMONS,John [EMAIL PROTECTED] wrote:
[snip]
Is it possible to do this from the command line ?
Thanks
John
John,
Sorry, that's not possible from the command line.
If you are using an 0.85 build, you could use functions to evaluate
the property whose name is contained in ${test}...
echo message=test = ${test} /
echo message=${test} = ${property::get-value(test)} /
Note in the second line that the property 'test' is being evaluated
and passed as an argument to the property::get-value function.
See
http://nant.sourceforge.net/release/latest/help/functions/property.get-value.html
and
http://nant.sourceforge.net/release/latest/help/fundamentals/expressions.html#expression-syntax
for more details.
--
Troy
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Rational behind not supporting basedir?
On 6/30/05, Martin Aliger [EMAIL PROTECTED] wrote: Hmm, is there any way to share script between Ant and NAnt and still using proprietary features of both? something like conditionals? Maybe this could be solution. If not, propably both teams would be needed to code it... Ant and NAnt are currently fundamentally un-interoperable, if only because Ant tests (if/unless) are based on property existence, while NAnt tests are based on evaluation to 'true'. And as Ian mentioned, that's just one source-level incompatibility... there are plenty more! But that being said, I'm not sure what the goal of interoperability of scripts between Ant and NAnt is. That sounds like asking for source-code interoperability between C# and Java... sure it might be nice in a couple of cases, but however similar the structure of the language they each have their own exclusive constructs and foibles. Or to put it a different way, it just doesn't make sense :-) What's wrong with using Ant to run Ant scripts, and using NAnt to run NAnt scripts? If you have a situation which Ant can deal with but NAnt can't, then use Ant... and vice versa. The only reason I can think of to try to run an Ant script in NAnt is to port it across because there is a feature in NAnt that you want to take advantage of... but by definition, this feature is not available in Ant so interoperability is impossible. Is there some other reason that I'm missing? -- Troy --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: [Nant-users] Problem with exec and input redirection to file
As an interim measure, it would probably be easier if the exec could
detect the use of redirection (|) and prepend the command with
either cmd /c or sh, depending on environment... that way, people
could use commands they are familiar with and get the full power of
redirection using NAnt, and it would be easier to port existing
scripts into NAnt in a piece-by-piece fashion.
That might be easier, though I'd certainly like the shell to be
configurable. But I don't believe NAnt will ever be a total replacement
for shells or scripting languages, nor should it be. If you're running
two different programs in a single NAnt exec, then I think it's clearer
to just create a script that does it and have NAnt just call that
script. A major reason that scripts become unmaintainable is that
people don't refactor by extracting functions; the same applies to NAnt.
Gary
Moving this one to the developers list, because I think I'd like these
ideas documented (in-list) a little more...
I have no issues with making the shell configurable, that's definitely
a Good Idea, although the actual nature of how to configure it would
probably need discussion. Would it be a normal (magical) property, or
a special parameter like the logger? Presumably it could be
overridden locally by the exec task itself?
I'm not sure that I understand what you mean by using an external
script to run multiple programs, but if I do then I don't think I
agree with you... if the programs are chained in a single expression,
then that could be encapsulated in a single exec call (delegating to
the shell). If there are several programs to be run in some order,
then that's flow control, which I think is more part of NAnt's
territory, so makes more sense to use multiple exec calls. The only
exception to this last that I can think of is where you want the
combined output from each program to be concatenated into a single
file - this (intent) would probably be more obvious with a single
exec call catching the output than with multiple exec calls with
the same output (does exec even support appending to the output file
rather than overwriting?)
An example of the first... say there's a legacy script which lists all
the files in a directory, sends it to a perl script for processing,
then pipes the result through an ftp client. The easiest way for this
to be ported to NAnt is if it could be brought across intact:
exec program=ls commandline=| perl makeftpscript.pl | ftp /
If NAnt were to introduce pipe support, then this could be split into
multiple execs and dependence on the shell would be diminished...
exec program=ls output=|ftp1 /
exec program=perl makeftpscript.pl input=|ftp1 output=|ftp2 /
exec program=ftp input=|ftp2 /
In this example, using NAnt pipes rather than a single exec probably
decreases maintainability of the script by itself, by increasing cut
and paste (in the pipe names)... but the idea is to add extra
opportunities to improve the script - perhaps the perl script could be
replaced with a NAnt script element in C# (or whatever is the
incumbent language in the organisation), reducing the number of
scripts to track and maintain, and the number of languages in the mix
- slowly improving the maintainability.
Also, pipes could allow the circumstance mentioned above (multiple
programs whose output is combined into a single file) to be naturally
performed in NAnt:
output-pipe name=|file /
exec program=cmd1 output=|file /
exce program=cmd2 output=|file /
write-pipe name=|file file=${filename} /
Then again, I'm not porting or maintaining build scripts at the
moment... maybe this is all just adding extra features to NAnt that
will need to be maintained that won't actually improve the language,
just provide more options for how things can be done.
Thoughts or input from others solicited and encouraged.
--
Troy
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] FW: [Nant-users] How to generate the doc on demand?
Just a pie-in-the-sky (whatever that means)...
These kind of issues aren't all that uncommon in builds... how feasible
is a meta-element attribute that can be nested under any
element and decorates it with an attribute. If the
attribute meta-element supported if/unless and lazy property
evaluation, then it could be used to do the following:
csc target=exe output=...
attribute name=doc value=${doc} if=${property::exists('doc')} /
...
/csc
Disclaimer: concept blatantly stolen from xslt attribute element.
I haven't looked at NAnt's xml deserialisation code, so I don't know
how feasible it is for one element to modify the contents of another
element on deserialisation... which would be much preferable (IMHO) to
having to explicitly code support for the attribute meta-element in all
tasks that might use it.
Thoughts?
-TOn 4/21/05, Julien Sobrier [EMAIL PROTECTED] wrote:
Hello, From the same source files, I need to create a couple of builds fordifferent frameworks, different debug values, ... and 1 with a doc.So I define the main build:task name=build /task
Then, for each build I want to create, I set-up the properties and do acall to build:target name=debug...property name= /call name=build /
/targetThis way works fine, except to generate the doc: I need to be able toswitch fromcsc target=exe output=../csctocsc target=exe output=... doc=../csc
I don't know how to do that inside buildAny idea?Thank youJulien---This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved increating, integrating, and deploying reporting solutions. Free runtime info,new features, or free trial, at:
http://www.businessobjects.com/devxi/728___Nant-users mailing listNant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users-- Troy
Re: [nant-dev] FW: [Nant-users] How to generate the doc on demand?
On 4/21/05, Gary Feldman [EMAIL PROTECTED] wrote:
This looks like a good idea, but could be difficult to do generallyacross all tasks.
I think there is a way to do it, but it is a little more complicated
than I like... Basically the NAnt.Core.Element class could be
extended with late binding attributes, and an entry point defined to
specify the time that these attributes should be evaluated. This
should work for tasks and targets, because they can bind when Execute
is called... not so sure about data types... or even if this should be
applied to anything but tasks! Dynamic dependencies,
anyone? Wouldn't work, would it? For that matter, some
attributes should never be dynamic even on tasks, like if/unless.
Maybe these properties could be declared static-binding?
Anyway, I might have a play with it over the next few weeks, and if I
don't find any nasty side-effects with targets or other elements, then
I'll submit it as a patch post-0.85.
PS- no offense, but some of the code to initialise the project and process the build file could use some refactoring :-)
In the meantime, a simple approach that works today is to duplicate thetask invocation with if/unless attributes, and use a property to
indicate which to do:In the setup targets:property name=generateDocs value=true / !-- or false --In the build targets:csc target=exe output=... doc=... if=${generateDocs} /
csc
target=exe
output=...
unless=${generateDocs} /It's annoyingly verbose, but I use this idiom frequently.
I think most people use it, because it's currently the only way to do it :-)
It gets exponentially more annoying the larger the element needing
repetition is, though. (IMHO) Allowing dynamic attributes seems
like a much more scalable and maintainable solution for the build
script author.
-- Troy
Re: [nant-dev] FW: [Nant-users] How to generate the doc on demand?
On 4/22/05, Ian MacLean [EMAIL PROTECTED] wrote:
somthing like this could be a good solution. Another possibility is tohave a way to set an attributes value such that its equivalent to it notbeing set - somthing like null for attributes. For example;target name=notdoc
property name=docFile value=${property::null-value()}/target csc target=exe output=... doc=${docFile}/Ian
That certainly looks simpler to implement, and it seems equally
powerful in terms of optional attributes. I think I'm leaning
towards this as a better solution... because it doesn't introduce any
new structures the learning curve should be lower; it also doesn't
require any arbitrary rules like cannot dynamically set
if/unless. Possibly the only issue that I can think of is a
nit-pick... where would you document the null-attribute behaviour so
people can find it?
I guess the _expression_ help page for new users, and the release notes
for old users? I just wonder if the _expression_ page isn't the
obvious place to look for attribute behaviour.
-- Troy
[nant-dev] Patch to documentation (fundamentals/expressions.html)
liCalling a functionp/p
pcodelt;echo message=The current date is:
span class=_expression_${/span/code/
p/li/aa href=../functions/datetime.now.html
datetime::now/a()} /gt;pThis will output the current date and time./
pshould beliCalling a functionp/
ppcodelt;echo message=The current date is:
span class=_expression_${a href=
../functions/datetime.now.htmldatetime::now/a()}/span/gt;/code
/ppThis will output the current date and time./p /li
-- Troy
[nant-dev] NAnt home page
The new home page doesn't have a link to the NantContrib page any more... -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Redesigned homepage
On Sun, 20 Mar 2005 09:46:28 -0800, brant [EMAIL PROTECTED] wrote: Is there any reason why we don't just use the existing Wiki as the Default Home page; and build up the content from that? I'm not so sure this is a good idea. I think a wiki is an excellent collaboration device for support, because it can be updated easily and by any concerned party... but I think these features actually make it a *bad* match for a home page. This is where the official information regarding the project should be found. Of course, you could restrict edits to the official pages to the regular contributors, but then why are you using a wiki? In addition, if you look at the content of the menu in discussion, 90% is located in the release folder, which contains generated html pages and doesn't mesh well with the wiki world. Wiki sites are supposed to be structure-simple and content-rich. I think a project home page needs to be structure-rigid as well as content-rich. This doesn't mean that the wiki doesn't have a place, but it doesn't have to be the main home page to be a useful resource. -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [Nant-dev] Good example of task unit tests
Marcin, I don't have a link to good unit tests right now, but I do have some suggestions that unit tests should follow... * A good unit test (fixture) should set up its required environment before running its tests, and tear down the environment afterwards. * A good unit test tests *only* the code it is trying to test. That is, it won't fail because of some other code. Unit tests are particularly difficult to write when external resources are involved, because of these (suggested) requirements. In particular, unit tests for subversion tasks mustn't assume the existence of any repository, at any location. Someone may be trying to build (and test) NAnt on a machine with no internet connection, and no local subversion server, and this shouldn't fail due to unit tests. One way to get around this is to test for the suitability of running the tests and fail in the setup method if the required environment for the tests is not found. This will mark the tests as not run instead of failed, and so won't cause the build to fail. The VC++ tests deal with this in a similar, but slightly different way: http://cvs.sourceforge.net/viewcvs.py/nant/nant/tests/NAnt.VisualCpp/Tasks/ClTaskTest.cs?rev=1.8view=markup (or http://makeashorterlink.com/?E2CF526BA ) -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Redesigned homepage
Okay, I no longer like css. It seems like every single web page I try to design requires some combination of relative and absolute sizes that is difficult to impossible to achieve in css. For me, anyway. Basically this means I don't have anything html-y to show for my efforts, but attached is a suggestion for re-organisation of the hierarchical layout based on my interpretation of comments to date :-) Criticism is encouraged, the more constructive the better. Imagine that the XML is the source for an XSL transformation that would generate the html menu, assuming I ever got my styles working. Basic commentary: * I've incorporated Gary's suggestion that the things that people are most likely to want are highest in the list. * I'm not using the /release/latest symbolic link so people's bookmarks (probably to documentation) will stay correct for the version they are using even if a new version is released. ie- the bookmark points to the version they are using, not the 'latest' version. * Old documentation and old releases are available through the archive links, rather than directly from the menu. Still easy to get to, without cluttering up any pages. With regard to the styles side of things, I was trying to incorporate another of Gary's comments and make the click target areas for both the tree expand/contract widgets and the links larger, to make them easier to click, as well as making links more obvious. I also like the idea of somehow marking external links as such, as the CruiseControl website does (I like _that_ part of the site ;-). Bombs away, -- Troy menu.zap Description: Binary data
Re: [nant-dev] ResourceUtils
On Wed, 23 Feb 2005 10:36:40 +0100, Giuseppe Greco
[EMAIL PROTECTED] wrote:
On Tue, 2005-02-22 at 09:41 +0800, Troy Laurin wrote:
[DCL]
Would you suggest something like this?
sealed class ResourceUtils
{
private ResourceUtils() {}
public static readonly ResourceUtils Instance = new ResourceUtils();
...
}
...
string errorMessage = ResourceUtils.Instance.GetString(NA1001);
That works fine too, but looking at
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/singletondespatt.asp, on .NET the result is
exactly the same as with the double-checked locking pattern
That is exactly what I would suggest.
Note that the result is exactly the same as with double-checked
locking, but the implementation is very different:
Using DCL, you have to guard against multiple threads attempting to
construct your object at about the same time, and you need a memory
barrier (or a volatile field) to ensure that the object created by the
first thread is visible to the others.
Using inline initialisation, you are guaranteeing that the object will
be completely constructed before anyone tries to access it, and a
side-effect of this guarantee means you no longer need memory barriers
to effect visibility. Or rather, the memory barrier you have to pass
to access the class definition (exactly once, the first time you
access the class) also suffices for the member.
Oh no! Java? Pfui!!! I come from C/C++... and my bibles were
Effective C++ and More Effective C++ by Scott Meyers...
There's no need to get that way, if you believe in good programming as
well as effective programming. There's a lot of (worthwhile) things
that you can do in C++ that are impossible (or at least don't make
sense) in Java, but not all that many projects need to do that kind of
thing.
Anyway, there's no reason why a Java programmer can't understand
what's going on beneath the covers, too :-) I think of myself as a
Java programmer, but I cut my teeth on C. (Actually, I cut my teeth on
Basic, then moved onto Pascal at school, then worked in C after
that... but you get my point)
j3d.
Peace,
-- Troy
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Hi
On Wed, 23 Feb 2005 10:00:40 +1300, Orion Edwards [EMAIL PROTECTED] wrote: Hi, just joined this list because I'm planning on transitioning our current build process (which is a big mess of shell scripts under cygwin) over to NAnt. Thus far I like it a lot, however there was one critical thing which NAnt didn't do, and which I couldn't find anything indicating how I might do it - which is to continue the build upon project failure (after running failure actions such as emailing), rather than just dying on the spot. As such I fixed it myself (score +10 for Open Source)... If anyone else has already done this or knows of a more 'normal' means, can you please let me know, otherwise here's some patches for 0.85-rc2. Orion, NAntContrib RC2 has a trycatch task which you can probably use to effect the same behaviour as you've patched in yourself. http://nantcontrib.sourceforge.net/ http://nantcontrib.sourceforge.net/release/latest/help/tasks/trycatch.html [snip] I'm kind of expecting someone to come back and say 'no we don't want that, go away', but if by some small chance someone wants to include it, if I have to jump through any hoops before submitting patches (signing agreements/etc) then could you point me in the right direction? Usually, there is nothing that needs to be done that can't be done via tasks instead of by modifying the core. Of course, you have the source so there's nothing to stop you from doing so, but having a custom core would probably make upgrading much harder than if you use custom tasks. Of course this is all IMHO, you are more than welcome to use whatever method works :-) Thanks for the great product and for your time, Orion. Thanks for your support, -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] ResourceUtils
Greco Giuseppe wrote:
There are also performance issues; actually, the code
for getting a localized string is as following:
public static string GetString(string name, CultureInfo culture)
{
if (resourceManager == null) {
lock (typeof(ResourceUtils)) {
if (resourceManager == null) {
Assembly assembly = Assembly.GetCallingAssembly();
resourceManager = new ResourceManager(
assembly.GetName().Name, assembly);
}
}
}
return resourceManager.GetString(name, culture);
}
In the code above, the lock takes place only once (the first
time a string is retrieved), assuring good performance.
In the code above, there are unfortunately also correctness issues.
Ref:
http://weblogs.asp.net/oldnewthing/archive/2004/05/28/143769.aspx
http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf
The article on this page seems to imply that DCL is fixed in .Net, but
they still recommend using simple static initialisation.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/singletondespatt.asp
Also, I very much doubt that DCL is fixed in .Net... any virtual machine
with a memory model that would allow DCL to work without explicit
volatility would be unlikely to be performant in multithreaded
situations in which volatility were not required.
It's possible that DCL with an explicitly volatile member will work in
.Net, but I'm not familiar enough with .Net's memory model to know if
this is actually the case.
Adding the functionality to register additional assemblies,
the lock would take place always as demonstrated in the following
code chunk:
static ResourceUtils()
{
resourceManagerDictionary = new ResourceManagerDictionary();
}
public static void RegisterAssembly(Assembly assembly)
{
lock (resourceManagerDictionary) {
resourceManagerDictionary.Add(assembly.GetName().Name,
new ResourceManager(assembly.GetName().Name, assembly))
}
}
public static string GetString(string name, CultureInfo culture)
{
string localizedString = null;
ResourceManager resourceManager = null;
lock (resourceManagerDictionary) {
foreach (DictionaryEntry entry in resourceManagerDictionary) {
resourceManager = entry.Value as ResourceManager;
localizedString = resourceManager.GetString(name, culture);
if (localizedString != null) {
break;
}
}
}
return localizedString;
}
The methods RegisterAssembly() and GetString() must be kept
synchronized...
What do you think about?
Why doesn't GetString in this section restrict itself to the
ResourceManager for the calling assembly?
On an unrelated note, is there any reason you use a static initialiser
block instead of inline initialisation of your static member?
Regards,
-- Troy
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Windows installer for binary distribution.
Ian MacLean wrote: Perhaps we should explore a new mechanism for extension libraries in NAnt, with inspiration taken from the Java jre/lib/ext idea... 4) Install NAntContrib to a different folder, and add an xml descriptor/locator in NAnt/bin/ext which describes the library. why not extend NAnt.exe.config rather than adding another config file. One of the things I like about the Nant model is that you don't *need* to have a task registration scheme the way Ant does because of the attribute based auto-scan mechanism. I'm looking at a principle of minimisation of damage. No matter how badly you (or some automated task) break the xml structure for the library you are trying to install (or modify or uninstall), you can't stop anything but your library from working. Conversely, if NAnt.exe.config doesn't parse, NAnt doesn't work. I'm not talking about describing the tasks in the locator, just a simple xml file in the order of: library name=NAntContrib description Optional tasks for NAnt /description assemblies assembly location=C:/path/to/NAntContrib.dll / /assemblies /library Also, it would be reasonably simple to create a registerlibrary (and deregisterlibrary?) NAntContrib task to create this locator dynamically. except that you couldn't register NAntContrib itself if you didn't already have it registered in order to be able to use those tasks :) The NAntContrib build script could use loadtasks to load its own tasks before registering itself. As a bonus, it provides a poor man's self-test mechanism... if the tasks don't load, it can't register itself ;-) I just think such a register task belongs more in NAntContrib than NAnt core. I still think that it would be better to extend the existing config file extra functionality is required. It already allows you to specify paths to scan for assemblies and I think to exclude specific assemblies. But not to give assemblies or groups of assemblies names, so you could then exclude those assemblies when running a particular build script through commandline options. It may be the case that this last isn't a good idea, I still think that multiple xml fragments is less fragile and more manageable than one mammoth xml file... not only for the damage minimisation, but because you can easily tell (at a glance) what libraries are set up in a particular installation by scanning a directory, but scanning through an xml file to see which assemblies are referenced is more time consuming. Regards, -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Windows installer for binary distribution.
From: [EMAIL PROTECTED] Option 4 looks like an elegant (but long term) solution. How about a another radical proposal: If there's interest, I might be able to put together a proof-of-concept this weekend. The NAntContrib installer also installs a suitable version of NAnt PROS: One install installs both. Environment vars, paths all fixed up correctly. Suitable versions of NAnt/Contrib released as a package. CONS: Tightly coupled (joined at the hip more like). If NAntContrib lags (in releases), you don't get the latest version of NAnt (easily anyway). This sounds like a reasonable immediate compromise, but what would the NAntContrib installer do if NAnt (by itself) was already installed? Installing over-the-top might be a bit rude :-) -- Troy Snipped parts of this thread can be found at http://www.mail-archive.com/nant-developers%40lists.sourceforge.net/ms g0.html The mailing list archive looks much nicer than it used to, incidentally :-) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] property overwrite attrib
Jamie Briant wrote:
Does this not seem outstandingly dangerous to anyone?
property name=build.config value=Bananafanafofana
unless=${property::exists('build.config')} /
Its just asking for errors where only one of the build.configs is
changed. Is there a good reason that the following is deprecated?
property name=build.config value=Bananafanafofana
overwrite=false /
James,
I'm not sure why the first would be dangerous but the second not... they
are functionally identical!
That's actually why the 'overwrite' attribute has been deprecated... it
is a widely misunderstood property, and the unless test is considered
much more explicit in its intent. That is, set this property unless
it's already set. A default value, if you will.
Regards,
-- Troy
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Suggestion for call element
Bruce Leggett wrote:
It would be nice if call target could accept parameters. Also if you could
specify a file the target is located in then there would be increased
encapsulation. Then code would be easier to maintain. Also if the target
could return a value. If there is something like this already then let me
know.
Example:
property name=BuildReturnValue /
call target=build fromfile=BuildTarget.build return=BuildReturnValue
parameter name=strSolutionFile value=MySolution.sln
/call
ifnot test=${BuildReturnValue= 'true'}
...
/ifnot
BuildTarget.build file contents:
!-- maybe not have the project for root element? --
target name=build
parameter name=strSolutionFile /
solution configuration=debug solutionfile=${strSolutionFile}/
return value=true/
/target
I haven't gave this much thought but I think you will get the idea. Maybe
make a function target? Anyways I just want to get somebodies wheels
turning.
Thanks,
Bruce Leggett
Software Engineer
Advanced Systems Technology, Inc.
850.475.4006
This has been discussed previously, and I personally like the idea.
It was (rightly) looked at as something that should be fully explored
and done properly if/when it's done... but I forget where the discussion
was left.
As a comment on the above, I'd suggest being able to specify parameters
as read/write so the calling target will be able to pick up any changes
made to the parameter by the called target, instead of using returns:
call target=build
call-parameters
parameter name=solution value=MySolution.sln /
parameter name=result property=BuildResult /
/call-parameters
/call
fail unless=${BuildResult == 'success'}No good!/fail
[...]
target name=build
expected-parameters
parameter name=solution required=true /
parameter name=result return=true /
/expected-parameters
do-stuff with=${solution} /
property name=result value=success /
/target
Regards,
-- Troy
PS- If your target is in another build file, then the nant task can be
used, which already supports calling a target with extra properties!
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Fileset / delete task change
Martin Aliger wrote: If this change is done, what about to lower verbosity when deleting non-existing files/folders also? I think verbose level is ok for that (todays it is error via BuildException). Martin Aliger Ant deals with this with a quiet=true: quietIf the specified file or directory does not exist, do not display a diagnostic message (unless Ant has been invoked with the -verbose or -debug switches) or modify the exit status to reflect an error. When set to true, if a file or directory cannot be deleted, no error is reported. This setting emulates the -f option to the Unix rm command. Default is false. Setting this to true implies setting failonerror to false. This seems to work well, because sometimes if the file/directory you are trying to delete doesn't exist it flags an error... typo in the build file? While the task is being changed anyway :-) -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Fileset / delete task change
Gert Driesen wrote: If I'm not mistaken, Ant only outputs a verbose-level message to the build log when a file, that is specified using the file attribute, does not exist. When a directory that is specified using the dir attribute does not exist, no message whatsoever is output to the build log. What the quiet attribute seems to do is (correct me if I'm wrong) : - no longer have the task fail when a file/directory that is matched by a fileset cannot be deleted (not just when it doesn't exist) - output the cause of a failure using a verbose-level message instead of using a warning level I'd have to look at the source to confirm this... I'm not running Ant in verbose mode, and I'm only deleting files :-P It wouldn't surprise me if you're right, though. What we should do is : - only output a verbose-level message when the file / directory pointed to by the file or dir attribute does not exist. Never fail the task if a file or directory specified using the file/dir attribute does not exist. This would match the behavior of Ant, except for the fact that Ant does not output any message when the directory pointed to by the dir attribute does not exist. This can be changed for the 0.85 release, and documented as a breaking change. Sounds good, except for the never failing... I'd still lean towards failing if the file/directory doesn't exist, because it will catch typos that otherwise might be difficult to track down. Perhaps an attribute 'failonnomatches' (fail on no matches... there has to be a more readable name?!) which would suppress the failure with no warning if the file doesn't exist, but fail if the file exists but can't be deleted - as opposed to 'failonerror' which would print a warning if the file doesn't exist. Or am I being too fail-safe paranoid? - add support for either a threshold or loglevel attribute to tasks (or both) after the 0.85 release. This will allow build authors to control build output on a task-level in a generic way, instead of introducing such a mechanism for specific tasks. I would suggest that it would be more useful (in general) to specify logging levels declaratively... that is, to specify an xml file (for example) which defines the thresholds and/or loglevels for each task; this could also be set through a task, then the configuration mechanism could be an included build file. Then again, I can see the point of task instance level log filtering, if you want to suppress logging for just a single task, but not for other instances of the same task in the build... would it be excessive to include both? -- Troy --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Separating targets into individual files
Neil Cowburn wrote: Heh. My mistake. It *seemed* to the executing the targets... Until I released that the targets were empty :) The include task is working as documented, but what I'd like to see is something analogous to include files in ASP where targets can be separated out into an external build file. This build file is the referenced in a master build file where the targets in the external build file may or may not be called from the master file. Using the nant task just doesn't cut it as you can't specific a target to execute. --Neil I don't understand what you mean that you can't specify a target to execute using the nant task... from the documentation http://nant.sourceforge.net/help/tasks/nant.html target string The target to execute. To specify more than one target seperate targets with a space. Targets are executed in order if possible. The default is to use target specified in the project's default attribute. nant buildfile=subproject.xml target=compile test / That behaviour has been around since (at least) 0.84... -T --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] I was wrong loadtasks
Gert Driesen wrote: - Original Message - From: Castro, Edwin Gabriel (Firing Systems Engr.) [EMAIL PROTECTED] Gert, you mentioned that we should not use the binaries in the bin directory of the src distribution. Could you explain why we get this error? I'm sure it's something trivial I haven't thought of... I'm just curious. The binaries that are included in the source distribution are only intended to be used to build a full version of NAnt. Is it worth renaming the bin folder to something like bootstrap? I guess that's not very standard. Perhaps a message in the header when running the bootstrap NAnt, to clearly indicate that you're not using the correct NAnt? Just a thought, -T --- 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] Looping constructs in NAnt
Alex Hildyard wrote:
Hi,
Is it possible to repeat an arbitrary set of tasks with a user-defined
exit condition? If not, could I propose this as a new task?
The foreach task lets you iterate over a certain set of prescribed
structures, but it would be nice to have something which simply provides
an uncomplicated
looping construct. For example:
Using foreach as an example, it would be a pretty simple task to create
a repeat task... I'm not sure this should be part of core NAnt though,
since it tends to undermine NAnt's position as a declarative language.
property name=var1 value=0/
repeat test=${var1 lt; 10}
echo message=${var1}/
property name=var1 value=${convert::to-int(var1)+1}/
/repeat
Currently I implement this with a call task, which doesn't really have
the right semantics, and means I have to initialise var1 from inside a
different
template, which tends to break the encapsulation.
target name=repeat
property name=var1 value=0 overwrite=false /
echo message=${var1} /
property name=var1 value=${convert::to-int(var1) + 1) /
call target=repeat if=${convert::to-int(var1) 10} /
/target
I'm not sure why you suggest that call doesn't have the right
semantics... you're simply re-rolling your iterative approach back into
a tail-recursive approach. The above should do exactly the same as your
repeat function, doesn't require pre-initialisation (the first time) and
is almost as concise.
If you use this often in your build, though, you would probably benefit
from creating the repeat task - the recursive approach will create
excessively verbose logs, especially when using an XML logger; also, any
loop variables will need to be reset (externally) before the second and
subsequent calls.
The other alternative is to wrap any loops in the script task. Use
could use Project.Execute to perform any required tasks... the example
above again:
target name=repeat-body
echo message=${var1} /
/target
target name=repeat
script language=C#
code![CDATA[
public static void ScriptMain(Project project) {
for (int i = 0; i 10; i++) {
Project.Properties[var1] = i;
Project.Execute(repeat-body);
}
}
]]/code
/script
/target
Regards,
-- Troy
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Add support for multiple filesets to the zip task.
Troy Laurin wrote: Gert Driesen wrote: Not only is this not as clean as having support for multiple filesets, it also causes problems for tasks that use the relative path to the base directory (like the zip task does to determine the directory within the zip file). Ant supports this in various (all tasks that use filesets ?) tasks. Rather than modify every task that uses a fileset, is it worth (is it correct?) modifying fileset to be self-nesting? For example, your references element from above might become: references includeset basedir=C:/Test / include name=AssemblyA.dll / include name=bin/AssemblyB.dll / include name=whatever/AssemblyC.dll / /includeset includeset basedir=D:/Test/whatever / include name=AssemblyD.dll / include name=AssemblyE.dll / /includeset /references or equivalently (slightly more concise): references basedir=C:/Test / include name=AssemblyA.dll / include name=bin/AssemblyB.dll / include name=whatever/AssemblyC.dll / includeset basedir=D:/Test/whatever / include name=AssemblyD.dll / include name=AssemblyE.dll / /includeset /references You could then play with includesets as required to ensure each included file has the correct relative path. If this isn't a bad idea, I could probably knock together a prototype next weekend... Thoughts? -- Troy Ping? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: install targets
Gert Driesen wrote: - I'm not sure if the rpm should contain both binaries and sources. Perhaps we might wanna consider two separate rpm's : one with only bin (and perhaps doc), and one with bin (only assemblies necessary to build NAnt), src, examples, doc. My 2c, probably the most useful download as a user is a binaries+docs package, especially if there's an installer option. The source package would usually contain everything but the binaries (?) This way requires two downloads if you want everything (cross-platform binaries and source), but you can download the source without having to download the binaries again, if you've already installed the binaries, for example. Maybe this last logic breaks down, since you'd get two copies of the docs if you downloaded both packages. How much value is there to a source-only package? If you can then build your own docs once the build is bootstrapped... -T --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [Fwd: Re: [Nant-users] Params vs properties redux was: Nant .85 not working with Draco.Net]
Gert Driesen wrote:
Ian MacLean wrote:
This seems to be causing a lot of grief. I'm really leaning towards
having a list of param elements at the project level and
allowing those and only those values to be passed on the
commandline. I'm not sure how feasible that would be with the way
we pass properties to nested builds but I think it would simplfy
things a lot and add extra benefits. For example:
project name=foo param name=param1 default=somevalue
description=my first commandline param /
Ian, I like the idea in general, but I'm not sure if the default
value for these properties is always known at design time, so users
would have to resort to the overwrite attribute anyway ... In the
future, I'm pretty sure we'll need to allow user input for specifying
property values (like Ant) : when a certain property is not specified
on the command line, the build author might want to have the user
asked to input the value ...
But as I said, I'm not sure the default attribute is all that useful,
as its too static : when you need to execute other tasks/targets to
determine the default value, the default attribute won't be of much
use I understand the problem you're trying to tackle with
this, but I'm not sure it will help users all that much ...
I don't think it matters how useful the default attribute is in general,
because there are a number of parameters for which a default value would
be the simplest and most consistent way to deal with them...
build.target for example would probably default to Release, but
could be overridden to 'Debug' on a developer's machine.
In cases where there is no useful default value, then don't specify a
default. If the value is required, then specify required=true
(default false or true?). I think the param mechanism gracefully
handles all of these situations.
Its great that we can use the description (and property name) in the
project help, and we could even add a required attribute to specify
whether a given property needs to be specified on the command
line
Add one more attribute, interactive (or ask-user, or something
else), which is a boolean attribute; if true, and the parameter isn't
specified, then request the user to input the parameter interactively -
this is certainly the most secure way to enter a password in cases where
the script can afford to be interactive.
A command-line parameter should probably be added to allow the build to
fail if any interactive parameters haven't been specified on the
command-line, so automated builds don't hang waiting for input... I
don't know if it makes more sense for this option to be on or off by
default - I'd probably swing more towards fail-on by default, since the
standard use of NAnt is in an automated build... and since parameters
are a new (potential) feature, a fail-secure mechanism won't break any
existing builds ;-)
The fact that all of this can be included in the -projecthelp output
would go a long way towards NAnt build scripts becoming self-documenting.
If you want a writable value based on a param you would set a new
property - the same as you would in c# code with pass by value method
arguments. Similarly it probably makes sense to have params and
properties in the same namespace so you coulndn't create a property
with the same name as an existing param.
I was going to say I don't really like this, because it has the same
issues as the current read-only properties do... but on examination I
changed my mind.
Using parameters that are declared as part of the build file, there is a
(mostly) static mechanism to ensure that no property is attempting to
overwrite a parameter. That is, most cases of properties clashing with
a parameter could be raised as errors when the build script is parsed.
Cases like property name=${property.name} / would sneak under the
radar, of course, but these would normally (?) be the exception.
We would also need to think about how to deal with this for nested
builds and included build files ...
My suggestion for this:
I think parameters are simplest and most intuitive when they are static:
As Ian suggested, you can only specify parameters that are defined in
the build file;
Nested build files called using the nant task then define their own
parameters. These parameters are passed through the nant task using a
nested params (or with-params) element which replaces (?) the
current properties element. Paramaters are not automatically inherited,
they must be explicitly specified in the nant task... this could be made
simpler by allowing something along the lines of paramsets, similar to
Ant propertysets:
param name=working.dir default=${nant.project.basedir} /
nant buildfile=worker.build target=do-stuff
with-params
with-param name=foo value=bah /
!-- If no value is specified, then the value of this project's
parameter is used. If this parameter isn't defined in this project,
then fail. --
with-param name=working.dir /
!-- Is it worth having a 'failonempty' parameter in a
RE: [nant-dev] Output redirection of exec
Ideally I want an application that is guaranteed to be
available that
has stable output, so a stable test could be added to the
ExecTaskTest
fixture. I guess the most robust/generic way to do this would be to
use a small purpose-build C# application as you suggest, but
is there a
way to ensure this application would be generated prior to running
these tests, and cleaned up afterwards?
either;
- build it during the regular nant build process and just
call it form the test or
- build it during the 'setup' phase of the test and delete it
during 'teardown'
Ian
Okay, I've come up against an error actually implementing this...
I've added the following fixture setup to the appropriate test fixture
(NAnt.Core/Tasks/ExecTaskTest.cs):
code
private const string TEST_EXE_FILENAME = ExecTestEmit.exe;
private const string EMIT_MESSAGE_FORMAT = {0} {1};
private const string EMIT_MESSAGE_COMMON = Printing to;
private const string EMIT_MESSAGE_STDOUT = Standard Output;
private const string EMIT_MESSAGE_STDERR = Standard Error;
private static FileInfo _testExe = new
FileInfo(Path.Combine(Path.GetTempPath(),
TEST_EXE_FILENAME));
public static FileInfo TestExecutable
{
get { return _testExe; }
}
[TestFixtureSetUp]
public void Init() {
string[] sourceTexts = new string[1];
string[] sourceNames = new string[1];
string[] imports = new string[0];
System.Collections.IDictionary options = new
System.Collections.Hashtable();
string outMessage = string.Format(EMIT_MESSAGE_FORMAT,
EMIT_MESSAGE_COMMON,
EMIT_MESSAGE_STDOUT);
string errMessage = string.Format(EMIT_MESSAGE_FORMAT,
EMIT_MESSAGE_COMMON,
EMIT_MESSAGE_STDERR);
sourceTexts[0] =
public class ExecTestEmit { + Environment.NewLine +
public static int Main(string[] args) { +
Environment.NewLine +
System.Console.Out.WriteLine(\ + outMessage + \);
+
Environment.NewLine +
System.Console.Error.WriteLine(\ + errMessage +
\); +
Environment.NewLine +
return 0; + Environment.NewLine +
} + Environment.NewLine +
};
sourceNames[0] = ExecTestEmit.cs;
options[target] = exe;
try {
Microsoft.CSharp.CompilerError[] errors =
Microsoft.CSharp.Compiler.Compile(sourceTexts, sourceNames,
TestExecutable.FullName, imports, options);
} catch (Exception e) {
System.Console.Error.WriteLine({0}{2}{1}, e.Message,
e.StackTrace,
Environment.NewLine);
}
}
/code
If this code is run standalone, it works correctly: an executable is
produced in the expected location, which runs with the expected output.
If run as part of the NAnt suite of tests, the following exception is
raised:
[nunit2] Cannot change thread mode after it is set.
[nunit2]at Microsoft.CSharp.Compiler.CallFunctionShim(String
dllname, String apiname, String[] texts, COMPILEPARAMS p, String ver,
Void* reserved)
[nunit2]at Microsoft.CSharp.Compiler.Compile(String[] sourceTexts,
String[] sourceTextNames, String target, String[] imports, IDictionary
options)
[nunit2]at Tests.NAnt.Core.Tasks.ExecTaskTest.Init() in
c:\app\NAnt\tests\NAnt.Core\Tasks\ExecTaskTest.cs:line 120
Does anyone have any suggestions on what is causing this error, or what
can be done to work around it?
-- 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 is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] INTERNAL ERROR regarding exec task
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Go, TerrySent: Thursday, 5 August 2004 4:58 AM Hi, First of all, thanks for providing this fantastic tool for .NET developers! Ive got this error message when I pass the string, "E:\Projects\Wsg\PrivateClient\Bernstein.com B78.1\..\setupfiles\PCWebApp2Setup-v1.78.2.115.msi" as program attribute. (note that I put actual double quotes) INTERNAL ERROR System.ArgumentException: Illegal characters in path. at System.IO.Path.IsPathRooted(String path) at NAnt.Core.Tasks.ExecTask.get_ProgramFileName() at NAnt.Core.Tasks.ExecTask.ExecuteTask() at NAnt.Core.Task.Execute() at NAnt.Core.Target.Execute() at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) at NAnt.Core.Project.Execute() at NAnt.Core.Project.Run() Please send bug report to [EMAIL PROTECTED]. When I run this in the command prompt it works fine. Could you have a look at this and fix? Regards, Terry Terry, Quotes are not needed inany file attributes in NAnt. The attribute is correctly interpreted as referring to a single file/path, even if there are spaces in the path. Does the build work correctly if you remove the quotes? Also, I believe the recommended way of specifying the full path to the program to be executed isthrough a combination of program and basedir attributes: exec program="PCWebApp2Setup-v1.78.2.115.msi"basedir="E:\Projects\Wsg\PrivateClient\Bernstein.com B78.1\..\setupfiles" / I don't know if this contributes to the issue at all. If you only have the full path and program in a single property, you can separate them using the path::get-file-name and path::get-directory-name functions available in NAnt 0.85 and later. Regards, -- TroyDisclaimer 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.
[nant-dev] Multi-threading NAnt (Was running a detached process from NAnt)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gert Driesen
Sent: Thursday, 5 August 2004 6:27 PM
To: sridhar; [EMAIL PROTECTED]
Subject: Re: [nant-dev] running a detached process from NAnt
Guess we need to add support something similar to the spawn
attribute in Ant : http://ant.apache.org/manual/CoreTasks/exec.html
Gert
If it's possible to spawn a process in the background, it would be nice
if there was a facility to rejoin the process at a later stage in the
build process... this would allow for orthogonal processes to be run
simultaneously, allowing throughput to be (greatly) improved in
multi-CPU or distributed builds.
exec program=bg.exe spawn=true pid-property=bg.pid /
other-bookkeeping-tasks /
rejoin pid=${bg.pid} /
Actually, along these lines, it would theoretically be relatively simple
to multi-thread NAnt itself... the target dependency model defines a
strong partial ordering of targets; NAnt could simultaneously execute
_every_ target that is eligible for execution, within definable
parameters such as maximum number of threads, or maximum simultaneous
compilation tasks.
This would make the slingshot task much more valuable, since it would
allow a solution with a wide dependency tree to be compiled in multiple
threads, or on multiple machines once NAnt supports distributed builds
:-)
The only downside to this approach (without further changes) is that the
dependency model is a little _too_ strong... if the test target depends
on the build target, then there is no way to run the test target without
also running the build target, for any reason (And there are various
legitimate reasons for doing this).
Anyway,
-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 is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] foreach task and a few other things
would folks consider adding an additional enumeration called ChildFolders or ChildDirectories to the type list? Rather than add extra attributes and work into foreach for variant behaviour, I would suggest using functions to vary the standard behaviour. eg: the path::get-file-name function should do what you need... http://nant.sourceforge.net/nightly/help/functions/path.get-file-name.ht ml This use is a bit out of line from how the function is named - perhaps it (or a variant that strips trailing path separators) could be called path::get-leaf-name? -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 is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Re: [Nant-users] NAnt 0.85 release notes + to-do's
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: Tuesday, 3 August 2004 9:46 PM To: Gary Feldman; Nant-Developers (E-Mail) Subject: [nant-dev] Re: [Nant-users] NAnt 0.85 release notes + to-do's Hi Gary, Thanks for the feedback. I've updated the description of this breaking change as follows : In previous versions of NAnt, the arg element (used by, for example, the exec task) would automatically add quotes for both file and value attributes in the command line generated by the task. That automatic quoting has been removed for value attributes (but not for file attributes). This change may break build files that assume that both arguments specified using the file and value attributes will automatically be quoted. Is this ok for you ? Gert FWIW, I think Gary's wording is better than mine :-) More verbose isn't bad, while more explicit is very good. I guess my reasons for talking about the Argument element type rather than the arg element is that a task is free to change the element name while using the same element type. With some thought however, this is not likely to happen, and the great majority of people probably don't care :-) -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 is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec
The ability to better-control the output of the exec task seems to be a common feature query... I'm looking at putting together a patch for this, but would like to solicit comment on my proposed solution: Create an element type ExternalProgramOutput with three attributes - file (FileInfo), property (string) and log (bool). ExternalProgramBase will include two extra (non-attributed) public properties - stdout and stderr, both of type ExternalProgramOutput. For each of stdout and stderr, if the file attribute is specified then output will be logged to the specified file; if the property attribute is specified, then the output will be stored in the specified property; if log is true then output will be logged as normal, if false then output will be suppressed from the build log. Each of these attributes is orthogonal. If the stdout and stderr elements both specify the same file to log to, then output is (safely) interleaved into the log file - so the file contents will be essentially identical to running the command on the console and redirecting both stdout and stderr to a file, the only major difference being that stderr will not break into any stdout output. If either the stdout or stderr element is omitted, it will behave exactly as if the element were included with null attributes. That is, output will be included in the build log but not redirected or stored in a property. ExternalProgramBase's output attribute will be deprecated but still work as-is. Examples: exec program=foo.exe stdout file=out.txt / stderr file=out.txt / /exec * Exactly the same behaviour as the current exec program=foo.exe output=out.txt / exec program=foo.exe stdout file=out.txt / stderr file=err.txt / /exec * Redirect standard output and standard error to different files. exec program=foo.exe stdout property=foo log=false / /exec * Silently store the output of the program in the property 'foo'. Any errors will still appear in the build log. I'm not confident writing tests for this for any platform other than Win32, however - basically I don't know what standard commands might be available that emit a known text to stderr, and don't have access to a machine to run the tests. Comment By: Gert Driesen (drieseng) Date: 2004-08-02 19:09 Message: Logged In: YES user_id=707851 I guess we should actually allow separate files for standard and error output. Please submit a feature request or a patch for this. I'm closing this bug now as I'm not able to reproduce this issue. 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 is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt 0.85 release notes + to-do's
-Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 August 2004 3:13 AM To: Troy Laurin; Nant-Developers (E-Mail) Subject: Re: [nant-dev] NAnt 0.85 release notes + to-do's Troy, I committed some changes to the release notes (and index.html). I'll upload a new nightly build soon. The changes look good. Apologies for the incremental changes, but there are a couple more: General changes: * This release of NAnt introduces support for expressions. should probably be * Added support for expressions. for better consistency with other general changes Commandline changes: * Deprecated -[defaultframewor]k option in favor of -[t]argetframework. should be * Deprecated -[defaultframewor]k option in favor of -t[argetframework]. * Added -emacs option could be * Added -e[macs] option Actually, regarding these last two, * The default logger will now also output the number non-fatal errors and warnings. this should probably be in general changes Finally, will the title for the 0.85-beta 1 release become 0.85-rc1 (or 0.85-rc 1), to be consistent with previous releases? I wonder if we should also use links for all the task/types headers (eg. csc) ? Not sure I like the layout that much when we change the headers into anchors/links. Previous releases in the file don't (hardly) include links at all... Adding links to the task/type headers doesn't affect the layout, does it? If it's a stylistic thing, then you could suppress the link underline and colour through the style sheet... Certainly, the file would become rather busy if each of these headings was underlined in blue. -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 is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec
-Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 August 2004 11:54 AM To: Troy Laurin Cc: Nant-Developers (E-Mail) Subject: Re: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec Troy Laurin wrote: I'm not confident writing tests for this for any platform other than Win32, however - basically I don't know what standard commands might be available that emit a known text to stderr, and don't have access to a machine to run the tests. you could write a small c# commandline app that writes to stderr and use that to call from exec. Why not just post the test code when you have it and those of us running non-win32 platforms can test it there. Ian Ideally I want an application that is guaranteed to be available that has stable output, so a stable test could be added to the ExecTaskTest fixture. I guess the most robust/generic way to do this would be to use a small purpose-build C# application as you suggest, but is there a way to ensure this application would be generated prior to running these tests, and cleaned up afterwards? -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 is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt 0.85 release notes + to-do's
This is probably just being picky, and I don't actually know what a good solution is... In /doc/index.html, one of the images is loaded from http://sourceforge.net This just means that the image will be broken when the page is viewed from a computer with no internet connection, or NTLM password authentication is requested when opening the page in Firebird if the network has a stupid NTLM web proxy installed. Not a big issue, but I thought I'd bring it up, while people are (kinda) thinking about this kind of thing. Release notes suggestions: (It's not all about complaints :-) General changes... * FilterChain support has finally been introduced to NAnt. should be * FilterChain support has been introduced to NAnt. (No need to give newcomers to NAnt the impression that things are slow to move in NAnt development) * NAnt will now report unknown attributes and child elements. could be expanded slightly, perhaps * NAnt will now report unknown attributes and child elements when parsing project files. (These are common symptoms of errors in the project file) Is it worth introducing a partial ordering to the list of general changes? Error reporting, new features, changed features, documentation changes...? Developer information... * The Task.LogPrefix property has been deprecated... should be * The Task.LogPrefix property has been deprecated and is no longer used... What needs to be updated in expression support? I just had a flick through, and it seems fine... I'll have a stab at some of the function documentation and forward this on in a later email. Would this stuff be most useful in the format found in the source files? How do you define a link to a html page in this format? Regards, and great work! -- Troy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: Tuesday, 3 August 2004 4:28 AM To: Nant-Developers (E-Mail); NAnt Users Mailing List Subject: [nant-dev] NAnt 0.85 release notes + to-do's Hi, The release notes for the NAnt 0.85 beta 1 are ready for review here : http://nant.sourceforge.net/releasenotes.html (and in cvs ofcourse). Please let me know if there's anything missing or incorrect. Before we can actually release the first beta, the following tasks need to be completed : - create and review release notes for NAntContrib - update documentation for NAnt expression/function support - the NAnt/NAntContrib admins still need to agree on the release (quality) I won't have time for this tomorrow, so if there are any volunteers for this: please don't wait for me to get started ;-) Gert --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers 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 is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Bug in Log.cs (LogWriter)
This is stupidly pedantic, but the implementation of WriteLine(string,
object[]) isn't consistent with its documentation.
That is, the string parameter will be correctly processed according to
the semantics of string.Format(string, object[]), but if there were any
prior calls to Write(string) then the currently stored message may
_also_ be formatted according to these semantics, which isn't very
obvious from the API.
The obvious implementation (to me) is to delegate:
public override void WriteLine(string line, params object[] args) {
WriteLine(string.Format(line, args));
}
If the formatting-in-retrospect behaviour is intended and correct, then
the documentation for this method should be updated instead... although
I can't think of a non-confusing way of describing this behaviour
succinctly.
Yours in pedantics,
-- 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 is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] XmlLogger is broken?
I need a streaming version of the xml logger[1] to continue testing with CruiseControl.NET (which expects NAnt's build output in the xml format emitted by XmlLogger)... I can create the logger class, but is there a simple way to register the logger against the build? The only way I can see to register the logger (or listener) is via the commandline, but there doesn't seem to be any way to specify an external assembly... Is it sufficient to create a (minimal) assembly with the cut-down logger and drop this assembly into the nant/bin folder, or is the logger required to be in the NAnt.Core assembly? Thanks, -- Troy [1] Actually, I just need a version of XmlLogger that doesn't hang the build after it has logged too much, seems to be around 4M. :-) 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 is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] XmlLogger is broken?
Gert, thanks for that, I'll if removing the buffering from the logger affects the build. I'll see if I can reproduce this later today ... Gert I just had a go at reproducing this using the script task logging in a tight loop, and I couldn't get it to hang (39M log file). I just looked in the xml log from last time it failed, and the last thing in the log is a BuildException: External Program Failed: C:\Program Files\GNU\WinCVS 1.3\CVSNT\cvs.exe (return code was 1) This message doesn't appear in the console, however (I'm using the default logger, with an xml logger listener)... but it does kind of explain why there is a log file at all. In fact, every time the build has hung has been during an 'exec' task. Although there doesn't seem to be anything wrong with the task (by) itself... the build process completes perfectly if the xml logger is removed as a listener. I can't spend too much time on this just now, we have a release going out the door next week, but I'll let you know if I find out any more about this. 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 is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [Nant-users] Re: [nant-dev] Typed properties
-Original Message-
From: Gert Driesen [mailto:[EMAIL PROTECTED]
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
On Wed, 21 Jul 2004, Troy Laurin wrote:
The destination type is string
unless overriden by type attribute. This is what most
people expect from assignment operation (in languages
like C++, C#, Java ...)
property name=a value=${convert::to-int('1234')} /
Again, if the default property type is 'string', then what is the
type of 'a' after this assignment?
string
Why I brought up these examples is that it is actually quite different
from behaviour in most compiled languages, in that the _value_ is
determining type... in most compiled languages, the _property_
(variable) determines type. Of course, scripting/interpreted languages
often use value-determined type to good use... at the cost of very weak
(or nonexistant) type checking.
mostly because it isn't always (often?) going to be apparent by
looking at the build file exactly what a property's type is. I
Property's type is always string unless specifically
overriden. Simple.
The problem arises in that the property's type may be set somewhere
distant in the build file, and then it's not apparent when looking at
the _use_ of the build file what the property's type is... so you don't
know if you're going to get a conversion exception or not until you
actually run the build.
All implicit conversion will be disabled and will cause an error
requiring you to fix your build file.
Notwithstanding, it's possible to do it without breaking
compatibility... you can't claim this if you are making a change
that turns a previously valid operation into an error!
Yes, but there's been no stable release of NAnt +
expressions.
Good point :-)
The nightly builds have been pushed quite strongly on the mailing
lists... but it would be simple to notify the lists that expressions
would need to be updated.
Having said the above, there is an alternative to disallowing
implicit type conversion (that unfortunately also breaks
backwards
compatibility) that means that all implicit type
conversions should be safe:
I've never been a particular fan of overloading the '+' operator
with string concatenation... if '+' only means addition, then it
would always involve numeric-conversion.
what about, for example, datetime values ? we currently
support the additional of datetime and timespan values ...
That's not in the documentation! :-)
I think that still works okay... because datetime and timespan can't be
converted (implicitly or explicitly!) to int or float, '+' can be safely
overloaded to date/time addition (and '-' to date/time subtraction)
without ambiguity.
Of course, whether it's a good idea to support operator overloading
(whether safe or not) is a separate question. A simple, though not
necessarily optimal, fix would be to remove the date-related
overloads on the operator, and instead use datetime:: functions. One
benefit to using functions rather than operators is that it's
immediately obvious whether you're incrementing the date or the time.
Because there is no implicit conversion
from boolean to integer, a boolean operand will cause an error.
Conversely if (for example) '|' means concatenation then it would
always involve (unambiguous) string-conversion.
I like the idea. We could replace '+' with a '.' as it is
used in PERL or PHP for example. Alternatively we could
have string::concat(...) for this purpose but this would be
too verbose.
I agree that string::concat is far too verbose for common use.
'.' as the concatenation operator was actually my first thought, as you
mentioned for its current use in Perl/PHP... but then I wondered what
the syntax would be when trying to concat the property 'str.prefix' with
'file.name', hence my suggestion of | (I think | or || is the string
concatenation operator in Oracle SQL, if anyone wanted a link to an
existing language ;-)
Alternatively, it could be required that operators are surrounded by
whitespace. (Basically upgrading the recommendation that operators are
surrounded by whitespace that's currently in the documentation)
Would just this last be enough type safety? It still includes
implicit conversion from string to int/float, but in a
(IMHO) safe fashion.
After some thought, I give this idea (using concatenation operator
other than a plus) +1. Gert, what do you think? This would
solve 99%
of all ambiguity problems without the need for typed properties.
Think I still need to give it some more thought ... I'm in
holiday mode today ;-)
Gert
Regarding Malcolm's comment that typed properties shouldn't get in the
way of the up-and-coming 0.85 release, I very much agree... but there's
also the fact that this discussion is somewhat aided by the fact that,
as Jarek commented, there currently isn't a stable release
RE: [nant-dev] Typed properties
Jarek, others,
I kind of like the idea of a property having a type,
but I have a few questions regarding implementation...
In the following...
property name="a" type="int" value="1234"
/
property name="a" value="5678"
/
If the default type for properties if none is specified
is 'string', then what is the type of 'a' after the two property assignments
above?
property name="a"
value="${convert::to-int('1234')}" /
Again, if the default property type is 'string', then
what is the type of 'a' after this assignment?
Regarding disallowing all implicit conversions in
operators, I can see why you might want this, but I have a feeling that it will
be more of a source for error than a means for preventing errors... mostly
because it isn't always (often?) going to be apparent by looking at the build
file exactly what a property's type is. I imagine this will lead to people
not using types because of the dangers of inappropriate implicit conversion, or
guarding against implicit conversion by extensively (excessively) using explicit
conversion.
Notwithstanding, "it's possible to
do it without breaking compatibility"... you can't claim this if you are
making a change that turns a previously valid operation into an
error!
Having said the above, there is an alternative to
disallowing implicit type conversion (that unfortunately also breaks backwards
compatibility) that means that all implicit type conversions should be
safe:
I've never been a particular fan of overloading the '+'
operator with string concatenation... if '+' only means addition, then it would
always involve numeric-conversion. Because there is no implicit conversion
from boolean to integer, a boolean operand will cause an error. Conversely
if (for example) '|' means concatenation then it would always involve
(unambiguous) string-conversion.
Would just this last be enough type safety? It
still includes implicit conversion from string to int/float, but in a (IMHO)
safe fashion.
Regards,
-- Troy
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jaroslaw KowalskiSent: Tuesday, 20 July 2004 6:45
PMTo: [EMAIL PROTECTED];
[EMAIL PROTECTED]Subject: [nant-dev] Typed
properties
Hi guys!
I'd like to propose the introduction of typed
properties to NAnt. Currently properties are stored as strings which has many
drawbacks, esp. when used within expressions.
For example:
property name="a" value="false"
/
if test="${a=false}"
...
/if
this test fails because:
1. "a" is stored as a string
2. equality operator promotes "false" literal to
string which becomes "False" (note the initial cap - this is what
Convert.ToString() does) the compares both sides as strings.
3. 'false' != 'False'
My idea is to:
1. Disallow ALL implicit conversions for
operators - to avoid such confusions
2. Add support for typed properties - to let
properties store values of types other than strings. It would involve type
checking on assignment and type-safe retrieval.
The proposed syntax would be:
property name="a" type="bool" value="false"
/
property name="b" type="int"
value="${1+1234}" /
When "type" is omitted - "string" is assumed by default for
compatibility.
The following would fail because of incompatible types:
property name="a" type="bool" value="3"
/
property name="a" type="int" value="false"
/
property name="a" type="float" value="zzz"
/
Assuming we disallow all implicit conversions:
property name="a" type="bool" value="true"
/
property name="b" type="bool" value="false"
/
property name="c" type="int" value="123"
/
property name="d" type="int" value="321"
/
property name="e" type="string" value="456"
/
echo message="${a + b}" / -- causes an error,today it
outputs 'TrueFalse'
echo message="${'aaa' + b}" / --- causes an error, today it
outputs aaaFalse
echo message="${'aaa' + convert::to-string(b)}" / --- outputs
aaaFalse
echo message="${c + d}" / -- outputs 444, today it outputs
123321
echo message="${c + e}" / -- fails, currently it outputs
123456
echo message="${convert::to-string(c) + e}" / -- outputs
123456
echo message="${c + convert::to-int(e)}" / -- outputs
579
Implicit conversion would still be applied when passing arguments to
functions:
Assuming
int fun(int k) { return k; }
echo message="${fun(e) + 1}}" / -- outputs 457
There are probably more consequences of this idea, if you see any danger
- let me know.
I'm awaiting your comments. If this idea passes, I'll prepare the
appropriatepatch. Initial feasibility study shows that it's possible to
do it without breaking compatibility.
JarekDisclaimer Message:
This message contains confidential information and is intended only for the individual(s)
[nant-dev] XmlLogger is broken?
I'm having an issue with using XmlLogger in my build... In particular, registering NAnt.Core.XmlLogger as a build listener causes my build to fail and hang, part-way through. I suspect that the logger's buffer is getting full (?), since the build hangs in different (but consistent) places depending on what build elements are included. Our build is rather noisy... The xml file that is found when the build hangs is close to 4M in size... but this in itself is confusing, because I understood that the xml log file isn't written until the build is complete? Which brings up the question... why isn't the xml log streamed to file? Logs are most useful when they are immediately available - if the build is terminated uncleanly (power failure, or malicious kill command) then the log-to-date can still be used, but if the log is buffered at all, then potentially valuable information can be (will probably be) lost. -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 is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt Namespaces
Rather than continuing this discussion (in particular, compare contrast) on this list, is it worth creating a page for the requirements/semantics of namespace support to the nant wiki pages? First cut of the page is up at http://nant.sourceforge.net/wiki/index.php/NamespaceDesign It currently doesn't have anything other than other than what's already been in email. And possibly not even that. Is it worth publicising the link on the users list, for discussion/requirements purposes? -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 is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt Namespaces
-Original Message- From: Gert Driesen I definitely agree with you here ... But I'm also convinced that this is not something we can/should implement right now. Our focus right now is to get a stable NAnt 0.85 released. It would ofcourse be interesting if someone could write a small paper on this topic right now, or implement a small proof-of-concept. Gert Without a doubt, an 0.85 release is the highest priority. This might be something that I'd be interested in picking up, but I wouldn't expect to be able to start on that until closer to the end of the month... in the meantime, the requirements and desired semantics in the build file can (should!) be worked out. -Original Message- From: Sascha Andres Hi, * Troy Laurin wrote on 13.07.2004 (10:17): Are you suggesting using the namespace for the class implementing the task, when referencing the task in the build file? This seems like it could be excessively verbose, to me. Well, I always use a short namespace. So I actually don't thought that it may get longer. What about using a task attribute [TaskNamespace(Sascha)] which forces me to use Sascha:TaskName.../Sascha:TaskName? May the proposed namespace attribute be a compronmise between convenience and too long namespaces? -sa Defining namespace in the class defining the task is an interesting idea and a possible solution... it's worth comparing this with the other viable solutions to see what's the best solution, both in terms of functionality as well as correctness and convenience. Rather than continuing this discussion (in particular, compare contrast) on this list, is it worth creating a page for the requirements/semantics of namespace support to the nant wiki pages? -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
FW: [nant-dev] NAnt Namespaces
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaroslaw Kowalski My vote: let's NOT support it - I'd say more - let's disallow it. Simplicity is an important thing. The only advantage of XML namespaces I see is technical beauty and XSD schema support for extensible intellisense - IMHO it's not worth it. The main reason for implementing namespaces isn't elegance or schema support... funnily enough, it's for namespaces :-) Lets say you use various third-party libraries containing tasks for NAnt. The ImageFoo library contains a task compress-image, which takes a bitmap file and converts it to a jpg, with attributes to specify compression levels and such. One day, you find that you need to use the NAntFileMagic library, which also contains a compress-image task... this one takes a fileset of images of any format, and creates a multiple-page png file which is gzip-encoded (for example... does png even support multiple images per file? (-; ) Without namespaces, you can't (realistically) use these libraries together. However, if you could explicitly namespace each library, then you can unambiguously use all of the features of both libraries. For example (using namespace syntax similar to Ant): loadtasks assembly=ImageFoo.dll uri=http://tempuri.org/imagefoo; / loadtasks assembly=NAntFileMagic.dll uri=http://tempuri.org/file-magic; / ifoo:compress-image xmlns:ifoo=http://tempuri.org/imagefoo; ... / Having said all of this, I tend to agree with Jarek in that namespaces aren't a particularly good way of doing this... at least, not the way Ant does it. Particularly clumsy is the need to specify the URI at least twice. I can see two obvious alternative syntaxes that are cleaner than the above. Note that they are put here for comment, I'm not necessarily recommending either of these approaches. First, the proprietary method, not using any special xml features... the way Ant decided not to go. To demonstrate using the above example: loadtasks assembly=ImageFoo.dll namespace=ifoo / loadtasks assembly=NAntFileMagic.dll namespace=magic / ifoo:compress-image ... / Pros: * Concise * Single definition of namespace * No confusing uris, with no purpose other than as a name Cons: * Not valid xml (undeclared namespace?). Xml validation errors can be removed by declaring the namespace (xmlns:ifoo=http://tempuri.org/ifoo;) somewhere in the build file, but it's annoying to have to. Second, use namespaces more as they were intended (As I interpret the intention for xml namespaces). Using the same example: ifoo:compress-image xmlns:ifoo=assembly:ImageFoo.dll ... /[1] Pros: * Single definition of namespace * The namespace uri is meaningful cons: * The namespace has side-effects, being loading of tasks, functions etc. There's actually an extra issue in using namespaces in a fashion similar to xml namespaces, whatever the approach... In (my understanding of) the current behaviour of loadtasks, any loaded tasks are available at any point in the build system that occurs after the task executes. Xml namespaces, on the other hand, are only visible in the defining element and all children. While this itself isn't a major problem, it lends itself to the concept of *redefining* a namespace... so a child element could redefine the namespace with a different assembly - once the child element has completed executing, the namespace returns to the parent's definition. This is probably a really bad idea, because it would be hard to understand or maintain build files. But if a build definition were spread across multiple included and called files, and if different people author various files, it's not an impossible circumstance. Finally, would this concept of namespaces introduced to tasks replace, extend, or not affect the current concept of namespace in functions? ie- load an assembly containing functions, specify the namespace 'myfoo'. If the assembly contains a function mystring::to-lower-case, would the function then be referenced by myfoo::mystring::to-lower-case? Also, I imagine that the use of namespaces may make the schema task more difficult to maintain, depending on the implementation chosen... 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.
[nant-dev] trycatch task ?
Clayton, Comments inline... -T -Original Message- From: Clayton Harbour [mailto:[EMAIL PROTECTED] For instance how would this be handled: try-catch property=buildfailure try asminfo ... / csc ... / nunit ... / /try catch fail .../ /catch finally call .../ /finally /try-catch 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. catch 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 ?... 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
RE: [nant-dev] NAnt Namespaces
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sascha Andres But don't we already have a possibility to decide what task is used? My personal version task uses my namespace. So why don't we give a task the complete name : namespace + taskname. Tasks in NAnt.* namespaces would be referenced without the namespace. And if there is no task xyz, tha tasks name in the script wouldn't be namespace.xyz but xyz. Are you suggesting using the namespace for the class implementing the task, when referencing the task in the build file? This seems like it could be excessively verbose, to me. Also, namespaces should also be always on or always off... I don't have any issues with leaving the nant core tasks to use the null namespace, but if a particular task is in namespace xyzzy, then it should always be referenced xyzzy.foo (or xyzzy:foo, or whatever namespace identifier is used). If namespaces are optionally specified, then people won't (in general) use them unless there's a conflict in advance... and that means that in your example with the developer using his own concat task he wouldn't use the namespace because it doesn't conflict - which means that it will still fail when it conflicts with nant-contrib, or worse, it would accept the nant-contrib task in precedence and the build would perform strangely! I appreciate the need for convenience, but since namespaces are a tool for a correctness problem, it's not valid to compromise correctness for convenience. -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
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 trycatch task with the errorproperty proposal :
errorproperty implementation :
asminfo ... failonerror=false errorproperty=buildfailure /
csc ... failonerror=false errorproperty=buildfailure
unless=${buildfailure} /
nunit ... failonerror=false errorproperty=buildfailure
unless=${buildfailure} /
if test=${property::exists('buildfailure')}
echo message=Build not successful! Check build log for
messages. / /if
trycatch implementation :
trycatch property=buildfailure
try
asminfo ... /
csc ... /
nunit ... /
/try
/trycatch
if test=${property::exists('buildfailure')}
echo message=Build not successful! Check build log for
messages. / /if
I think I'd prefer the trycatch (or try-catch) 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=detailaid=85319
8group_id
=31650atid=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:
property name=buildfailure value=false / asminfo ...
failonerror=false errorproperty=buildfailure /
csc ... failonerror=false errorproperty=buildfailure
unless=${buildfailure} /
nunit ... failonerror=false errorproperty=buildfailure
unless=${buildfailure} /
if test=${buildfailure}
echo message=Build not successful! Check build log for
messages. / /if
with:
property name=buildfailure value=false / trycatch
try
asminfo ... /
csc ... /
nunit ... /
/try
catch
property name=buildfailure value=true /
echo message=Build not successful! Check build log for
messages.
/
/catch
/trycatch
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 trycatch task to
NAnt(Contrib), similar
to what AntContrib has :
http://ant-contrib.sourceforge.net/tasks/trycatch.html
Can anybody come up
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 solution) 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? trycatch 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] Two broken testcases - edge case question
Matthew,
The new behaviour more closely follows the documentation, and as you say
this becomes consistent with handling of files... but any build files
relying on the old behaviour will of course break.
The fix is simple, to replace **/* with */**/*, but it may be hard
to diagnose if/when upgrading breaks your build script...
A note on your previous email...
2. foo/**/*.cs was being converted to foo/(^\\.*)*/[^\\]*.cs This
is now converted to foo/\\?.*[^\\]*.cs, also much faster.
foo/(^\\.*)*/[^\\]*.cs
Looking at the code for DirectoryScanner, how is it possible for this to
be produced? On windows, I get foo(\\.*)*\\[^\\]*\.cs. From looking
at the code, on unix/linux I would expect to get foo(/.*)*/[^/]*\.cs.
The conversion result would then be foo.*/[^/]*\.cs, which appears to
give exactly the same results.
I'm curious that taking out the ^$ anchors speeds up the search, since
there's an explicit comment in the DirectoryScanner source noting that
they are added to improve the speed... and it makes sense that including
them would reduce the amount of stringspace that would need to be
examined by the regular expression... then again, I haven't tried
comparing the speed of each regular expression, so I'm happy to accept
that my understanding might be flawed :-)
A couple of extra comments on DirectoryScanner...
Both the ToRegexPattern and ParseSearchDirectoryAndPattern methods
perform slash replacement. ToRegexPattern is private, and only called
from ParseSearchDirectoryAndPattern, so should be able to assume that
slashes are already replaced.
Just being picky, but shouldn't 'if (s.Length == 2 s[1] ==
Path.VolumeSeparatorChar) {' be 'if
(s.EndsWith(Path.VolumeSeparatorChar)) {'? This allows for platforms
that support named volumes, as well as just drive letters. Not that
there are any platforms like this around any more :-)
Regards,
-- Troy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Mastracci
Sent: Thursday, 8 July 2004 5:34 AM
To: Nant-Developers (E-mail)
Subject: [nant-dev] Two broken testcases - edge case question
It looks like the regex optimization broke an edge case:
**/* now matches the base directory, as well as any
subdirectories on a FileSet.DirectoryNames call. For
instance, in the following directory structure, all three
will be matched with a base directory of C:\foo:
C:\foo
C:\foo\bar
C:\foo\baz
The old behaviour would only match the two subdirectories.
Is this behaviour important to anyone? This is actually more
consistent, considering that:
file/**/*.cs
matches:
file/bar.cs
file/foo/bar.cs
file/foo/foo/bar.cs
**/ can basically be considered to be current directory or
subdirectories.
Matt.
---
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
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] checking task availability
Just to add a comment to this discussion... Well, CheckAvailability would perform the actual runtime check (using the XML configuration in the NAnt configuration file, or the behaviour specified by the task), and possibly throw an exception detailing the reason why the task is not available. The IsAvailable property would just call the CheckAvailability method, and return false if the CheckAvailability method throws an exception. I realise performance isn't a major issue in a build system, but the normal reason for having a test (IsAvailable in this case) is to try to avoid having an exception thrown. To this end, the actual runtime test could be separated into a private (protected?) method; CheckAvailability would delegate to this method and throw an exception on failure, IsAvailable would delegate and simply return false on failure. Still not sure about the name of the property/function though, kinda awkward to have task::exists and task::available. In order to determine whether a task can be executed you'd have to check the value of both functions ... It wouldn't be the first place this is found... to perform the check Is this property read-only requires testing both existence and read-only-ness. Then again, in both the property::read-only function and the task::available cases, I think it should be reasonable for the functionto represent an extended test. That is, property::read-only should return false if the property is not set, rather than throwing an exception. Similarly, task::available should return false if no task is defined for that tag, rather than throwing an exception. Let me know if I'm way off base, -- 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
