Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml type)
Yep, I expect that the XPathObjectNavigator needs a good deal of work
before
we can use it.
I think so too. Could we just borrow Bamboo code and modify it for our
needs? Both projects are under GNU licence... Still - it will be nice to ask
them if they do not mind. Anyway - write it from scratch shoudn't be very
hard (just reflection stuff) but needs extensive testing. Better use what is
already done [and well done!] :-)
See this message for my ideas of what needs to be done.
http://sourceforge.net/mailarchive/forum.php?thread_id=3707522forum_id=32775
Plus I'm sure there are many bugs that needs to be fixed and unit test
that
need to be written.
I'm hoping to spend a day or two next week getting things into shape, and
hopefully after that creating a new sf.net project for it.
Any help would be greatly appreciated :)
I'll gladly help you. Try use mine patches I sent before - they are good
ground to start playing with Bamboo. Write me (privatelly or here) when you
look into that - we could cooperate on this field.
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Matthew Mastracci
[EMAIL PROTECTED]
Cc: Scott Hernandez [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 6:41 AM
Subject: Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml
type)
Hi all,
I successfully include XPathObjectNavigator from Bamboo.Prevalence.
Script like this:
exec program=foo.exe commandline=1 2 3 failonerror=false
result taskoutput=/ExecTask/ResultCode property=resultcode/
/exec
echo message=${resultcode}/
now correctly writes:
[exec] foo.exe 1 2 3
E:\src\extern\nant\test2\test.build(21,3): External Program Failed:
foo.exe
(return code was 2)
[echo] 2
What is not so nice is:
1/ Bamboo makes object names from hierarichy based on their names. In
NAnt
we use custom attributes to customize names
2/ We could want to hide some names from result (or all public is ok?)
3/ Badly formed xpath do not throws exception but rather returns string
NAnt.Core.Tasks.ExecTask.
4/ Collections returned via xpath (e.g. /ExecTask/Environment) returns
as
NAnt.Core.Types.OptionCollection. Not very useful...
Maybe, I'm doing something wrong with Bamboo...
Attached are patched to NAnt sources + zip with needed Bamboo.Prevalence
sources.
Sources are alot simlyfied now (e.g. only one result element) and no
fail
checks yet. It is meant just to test this approach.
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml type)
Hi all,
I successfully include XPathObjectNavigator from Bamboo.Prevalence.
Script like this:
exec program=foo.exe commandline=1 2 3 failonerror=false
result taskoutput=/ExecTask/ResultCode property=resultcode/
/exec
echo message=${resultcode}/
now correctly writes:
[exec] foo.exe 1 2 3
E:\src\extern\nant\test2\test.build(21,3): External Program Failed: foo.exe
(return code was 2)
[echo] 2
What is not so nice is:
1/ Bamboo makes object names from hierarichy based on their names. In NAnt
we use custom attributes to customize names
2/ We could want to hide some names from result (or all public is ok?)
3/ Badly formed xpath do not throws exception but rather returns string
NAnt.Core.Tasks.ExecTask.
4/ Collections returned via xpath (e.g. /ExecTask/Environment) returns as
NAnt.Core.Types.OptionCollection. Not very useful...
Maybe, I'm doing something wrong with Bamboo...
Attached are patched to NAnt sources + zip with needed Bamboo.Prevalence
sources.
Sources are alot simlyfied now (e.g. only one result element) and no fail
checks yet. It is meant just to test this approach.
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]; Matthew Mastracci
[EMAIL PROTECTED]
Cc: Scott Hernandez [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 10:29 AM
Subject: Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml type)
It might be worth investigating what is possible with items in msbuild
and what use cases we can apply using this XPathObjectNavigator
solution.
John Lam posted some of his experiences using output items with msbuild
at:
http://www.iunknown.com/000379.html
Ian
I read that article and what I like about MSBuild (never tried it yet) is:
Task Name=MSBuild Projects=..\lib\lib.proj
OutputItem TaskParameter=TargetOutputs Type=ReferencePath/
/Task
transcribed into NAnt syntax something like (I use exec instead of
nant
task here):
exec program=foo.exe commandline=1 2 3
resultitem taskoutput=output/resultcode
property=resultcode/
/exec
so exec task returns some semi-xml result (not xml in any form, just
XPathNavigatable objects) which you could reference in resultitem (or
outputitem) subelement (common for all tasks) and copy its value into
property.
This could be very simple to use in many cases. Still I want to keep
possibility to fetch all semi-xml document from task to for example
iterate
with xmlforeach within failed projects:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
resultitem id=solresult/
/solution
xml-foreach refid=solresult xpath=failed/projects
...
/xml-foreach
How you like this?
+1 for XPathObjectNavigator. I was thinking about this myself. W
Could we use XPathObjectNavigator.cs file from bamboo? Does our and their
licence allow that?
I'll do test implementation now to see how it'll be.
Martin
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
ExternalProgramBase.cs.patch
Description: Binary data
NAnt.Core.Bamboo.zip
Description: Zip compressed data
Task.cs.patch
Description: Binary data
Re: [nant-dev] Re: Inter-Task XML Communication (WAS: new xml type)
It might be worth investigating what is possible with items in msbuild and what use cases we can apply using this XPathObjectNavigator solution. John Lam posted some of his experiences using output items with msbuild at: http://www.iunknown.com/000379.html Ian Yep - each task can survive on its own, but can use extra information from other tasks to perform a more integrated task or can just provide more information for other tasks to do the same (example eludes me at the current moment). *XPathObjectNavigator stuff: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/html/xml03172003.asp http://cvs.sourceforge.net/viewcvs.py/bbooprevalence/Bamboo.Prevalence/src/Bamboo.Prevalence.XPath/ +1 for XPathObjectNavigator. I was thinking about this myself. W The XmlSerializer stuff can create xml schema for us, is this what you mean? Yep. I didn't know if this was possible. If so, that rocks! ;) If each xml object could tag along an associated schema, this would enforce the validity of the object during user manipulation of the XML object, allowing it to be re-imported into the NAnt world at some later date. Are you saying that we would serialize these objects to disk for use by nant during another execution, or just during the current one? What is the application of this? Err... that was a think-o. By later date I meant later time in the build process. Still running on less than adequate sleep. ;) The xml documents should be in-memory items within NAnt as you mentioned earlier. This doesn't preclude having an xmlsave or xmlload task to persist them longer, however. Matt. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
