Title: NAnt on Linux
Hello folks,
Yesterday I began looking at NAnt as an alternative
to make...
Well, I really like it. I downloaded the last
stable version and tried to compile it on Linux
using mono... (yes, my development platform is
Linux and only Linux).
At first, I wasn't able to
It sounds like a bug. Please provide a cvs diff (with -u) for any changes
you want to the dev list.
If you need more directions please let us know.
I suggest TortoiseCVS if you are on windows. It is extremely easy to setup
and create diffs (it can do it from a directory too!).
- Original Mes
Sorry for my earlier post re: using filesets in . The expected
syntax isn't , it's . Still, when I use
, there's still problems. I found that it's because the
fileset in comparefiles isn't set up properly. Basically, there's a
bug. I've fixed it in my version of the source. I don't know where
>
>
>
> or
>
>
>
>
>
>
>
> What do you guys think?
OK. I know get the place of in the story and it makes
complete sense to me. Lose the old . Man, what a dud! :)
A single file or a fileset makes sense also.
>From your example, I can't tell whether the path= attribute is for a
s
Jean Rajotte wrote:
Ian, Tomas,
1) I prefer to because the name hides the
implementation (I shouldn't care when the task gets loaded).
but you do want those tasks loaded at that point - it would be useful to
have it log which tasks its found for debugging purposes.
2) I see Tomas echoes my co
Jean Rajotte wrote:
Really? A single, centralized config file would handle all my projects'
quirky requirements. I didn't get that from your schema. I still think
it's easier in some case to handle it on a project by project basis and
taskdef does that for me.
the load tasks proposal is on a pr
Tomas Restrepo wrote:
Jean,
Basically, the same as Ian proposes, but I'd have loadtasks examine the
contents and see if it references a file or a directory: if the former, just
load that one and that's it; otherwise scan for task assemblies. This would
give us all the functionality of the old Tas
Jean,
> I think tomas was saying there's no gain in losing taskdef, only loss,
> like my point.
True. But the alternative Ian proposes sounds good, as it
accomplishes the same as taskdef, but does it in a more nant-like way. I'm
happy to change a line or two in my buildfiles for this.
My only a
> > 1) I prefer to because the name hides the
> > implementation (I shouldn't care when the task gets loaded).
> but you do want those tasks loaded at that point - it would
> be useful to
> have it log which tasks its found for debugging purposes.
OK. I get it. Loadtasks is a better name.
Here's what I'm trying to do. According to docs, both and
compareFile="" will populate compareFiles, which is used in the
comparison. However, I find that compareFiles doesn't get populated
when I use fileset like follows. Plus, nant smokes because
_compareFiles is null and there's no assertion
I added fileset support to the NUnit2 task earlier - but this shouldn't
affect the assemblyname attribute.
Scott Hernandez wrote:
That assemblyname attribute is really a nunit assemblyname(FilePath). It
really needs to be a full filepath to the file.
I have updated the NUnit2Test to resolve the
Tomas Restrepo wrote:
That's cool. However, allow me to present an "alternative" point of view:
Why can't we have *both*? The argument I've been hearing since taskdef was
shunned (and I'm one of the ones that complained about this at the time) is
that the config stuff is more flexible and more ele
Ian, Tomas,
1) I prefer to because the name hides the
implementation (I shouldn't care when the task gets loaded).
2) I see Tomas echoes my concern in spades. "so what" if it's Ant-like
and klunky. It's just another tool. It doesn't preclude the
and the config file approaches. It just adds
Hi Ian, Jean,
Allow me to join this briefly... I'll let you guys return to your regularly
scheduled program afterwards :)
> >>Personally I find the taskdef mechanism a bit clunky for NAnt.
> OK to be more clear - the way taskdef works derives from the ant model
> where you have to register every
That assemblyname attribute is really a nunit assemblyname(FilePath). It
really needs to be a full filepath to the file.
I have updated the NUnit2Test to resolve the path relative to the project;
resulting in a full path qualified string sent to nunit. This change will be
in tonight's nightly buil
Jean Rajotte wrote:
Ian,
First, thanks for humoring me on this. I'm not sure whether I should
apologize for going on about this. I'm new here. My original impetus
for joining the list was that taskdef is exactly what I wanted and I
couldn't find it w/o hassle.
thats ok. You seem to have a valid
Ian,
First, thanks for humoring me on this. I'm not sure whether I should
apologize for going on about this. I'm new here. My original impetus
for joining the list was that taskdef is exactly what I wanted and I
couldn't find it w/o hassle.
> What I'm looking at adding is an additional setting
Ian,
Thanks for your reply. I understand the mechanics "integrating" my
tasks to the ${nant.location}, but it's beside the point. It seems to
me it's wrong-headed to deprecate a means of extensibility. It means
that anyone who upgrades NAnt HAS TO do something(s) extra in order to
re-drop their
Jean Rajotte wrote:
Ian,
Thanks for your reply. I understand the mechanics "integrating" my
tasks to the ${nant.location}, but it's beside the point. It seems to
me it's wrong-headed to deprecate a means of extensibility. It means
that anyone who upgrades NAnt HAS TO do something(s) extra in ord
This maybe silly, but instead of just giving a relative path to
bestbuy.enterprise.tests.dll, try giving it a fully qualified path including
the drive letter. This solved my problem. (See attached message.)
It already looks like you have part of the path, so all you need to do is
prefix it with yo
The usertask example was updated more than a month ago to remove the taskdef
dependency. In fact, there were a few mail threads about this, and its new
behavior.
I don't know of any other examples that used taskdef.
- Original Message -
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: <[EMAIL
Jean,
the reason its in nantcontrib is because its deprecated. To add new
tasks all you need to is drop the new task assembly in the same folder
as nant and it will *automatically* find all the tasks in it. See the
FAQ [1] and the "Writing a custom NAnt task " turorial[2] on the wiki [3]
I just
Here's the error and call stack I'm getting. Please let me know what might caused
the problem. Thanks.
-
INTERNAL ERROR
System.IO.FileLoadException: Unable to load file 'bestbuy.enterprise.tests'.
File name: "bestbuy.e
Yall,
I just spent too long looking for taskdef, then figuring out I have to
download bits from nantcontrib, than kludge this and that to make it
work, then finally have it.
IMHO, it belongs in Nant.Core. It's the first task that should be in
nant.core. Conceivably, it's the only task that could
Yes, throw an exception. In fact, throw a BuildException.
We have a failonerror attribute which dictates how this exception is
treated. The user can choose to ignore it, or let it stop the build. Also
there are targets that can be called on a failure, or success of a build.
- Original Message
I have a custom user task working pretty well but I have one other tweak
I'd like to make. I've noticed that ExecuteTask
returns void so I wasn't exactly how to signal NAnt if my task failed. I
had assumed that it would be bad to throw an exception from ExecuteTask
so the only other thing
26 matches
Mail list logo
