I have written (and included) a small project that shows what I mean.
The generated test assembly can be run using the Nunit2 Gui testrunner,
where the test passes. Using nant I get the following result:
Buildfile: file:///C:/Documents and
Settings/marnoldus/Workspace/Dev/Nunit2WithF
Forgot the example ...
-Original Message-
From: Arnoldus, Michael [mailto:[EMAIL PROTECTED]]
Sent: 23. januar 2003 11:49
To: [EMAIL PROTECTED]
Subject: RE: [nant-dev] NUnit, Nant and current directory
I have written (and included) a small project that shows what I mean.
The generated
Sounds good. I'm sure whatever you think is needed will help.
Right now the Task References are created by NDoc via the userdoc target.
It generates a html page for each task and an index page for them all. These
docs are generated by the xml code comments, but can be
supplemented/replaced by
--- Scott Hernandez [EMAIL PROTECTED] wrote:
Right now the Task References are created by NDoc
via the userdoc target.
The product of this process doesn't seem to be getting
checked in. The net result is, when you check out the
docs from CVS, the core part of the documentation (the
tasks
It should not be checked in. Once it is generated, it is stale and it is not
the source of documentation anyway.
Why do you want it checked into source control as html? (it should not be
edited in that form)
- Original Message -
From: Jeffrey McManus [EMAIL PROTECTED]
Sent: Thursday,
I understand that it shouldn't be edited directly, but
I think it should at least be checked in, because it
represents part of the distributable package of the
application. One objective of source code is to be
able to view, at a glance, the state of an application
(including its distributable
Jeffrey,
The source in cvs does represent the documentation at any point, not the
other way around. What your suggesting would lead to ever more dissimilarity
between a build and the docs in the system. We would need to check in new
docs whenever a source file is changed! That is just wrong.
--- Scott Hernandez [EMAIL PROTECTED] wrote:
The source in cvs does represent the documentation
at any point, not the
other way around. What your suggesting would lead to
ever more dissimilarity
between a build and the docs in the system. We would
need to check in new
docs whenever a source
Maybe working backwards from my original problem would
shed light on this. Let's take an example...right now
in the nightly builds there is support for a tag
called 'nunit2'. How would someone get access to
documentation on this?
The correct answer is:
Do a point release, already. The current
Jeffrey McManus wrote:
I'm accustomed to thinking of docs as a part of the
deliverable package and as such, something that should
be checked in. I'm willing to accept that not
everybody does it that way, though.
Having docs checked in makes sense if they are edited as html. Ours are
Having docs checked in makes sense if they are
edited as html. Ours are
generated. We should be updating the website
regularly with the latest
docs. Perhaps the nightlies should include this too.
Updating the website with documentation on features
that aren't in the latest stable build
No, there is no way to see the task refs unless you build the userdoc
target.
Note: The currently nightly are cvs snapshots, not builds.
We need a nightly/periodic build to do what you are suggesting. I am all for
this, and in fact I have a machine to do it, but there isn't enough time in
the
--- Scott Hernandez [EMAIL PROTECTED] wrote:
Oh. It sounds so simple, but this lever of
automation we do not have. It
would require cvs polling, or a linux build
environment on sourceforge.net.
Yep, I didn't mean it seriously -- hence the smiley
after the suggestion. (Although...I'm not super
Hi
I am running NAnt
version 0.8.0, and I see that the slingshot task isincluded
inversion 0.8.5 and higher. I am unable to access the nant site, and
keep getting TCP errors. So if anyone has the latest version, please can you
email it to me (Please embed it in a Word document, otherwise
14 matches
Mail list logo
