Robert Schneider wrote:
1. I have done all with a normal editor. Xml doesn't seem to be
advantageous in my case. How could I benefit from the xml format? What
do you do with it?
XML is a pretty hideous language for human use. I seem to remember
someone saying a while back that the inventor of Ant now regrets using
XML (so you've now heard it third hand; don't quote me).
Personally, I edit NAnt with GNU emacs and the nxml-mode package. (This
uses a Relax NG schema that I originally generated from the NAnt XSD
schema, but have since maintained manually; I'd be glad to make it
available to any other emacs users.) The other possibilities I've seen
mentioned are using Visual Studio and a commercial product called
Nantpad, though obviously there are many XML editors out there. I can't
comment on Nantpad, which is specifically targeted at NAnt, but there's
little value in a generic XML editor, including emacs or Visual Studio.
They just make the XML a bit less painful. They can do some syntax
checking and completion, but since NAnt has its own expression language,
that's just half the battle.
The main advantage of XML is that the NAnt code can use a standard
library to do much of the parsing, but that doesn't help the users. You
could get some mileage out of using XSLT to generate NAnt scripts from
template files. I've heard of people doing that for CruiseControl.Net
(which also uses XML), but I don't recall any examples of doing it with
NAnt that seemed generally useful.
2. I guess I think too much in a programming language and so I miss some
things.
That's a common problem for many of us. NAnt tries harder than Ant to
be a scripting language, but it isn't really, and there are limits to
what it can do well.
Is it good to have only global properties? Why are there no
local properties?
It's important to remember that all properties are global as far as NAnt
is concerned. Local properties are an interesting idea, but NAnt is
still at version 0.85 (i.e., pre-release), so they won't happen anytime
soon.
I get around the lack of local properties through a simple naming
convention: Anything that's global gets a hierarchical name using
periods, e.g. ${build.src} or ${test.results.dir}. Anything local gets
a simple name, with no periods. My rule is that if there's no period in
a property name, then it must be reinitialized by any target using it,
and no target may depend upon it's value after a <call> statement.
There are rare exceptions, where a target has been refactored so that a
simple name gets shared between targets, but that's only when the
targets are tightly coupled.
And also functions would be nice. If this view on nant
is wrong how else should I see at it?
I'm not sure exactly what you mean by functions. NAnt has an expression
language with many built-in functions, but that doesn't sound like what
you mean. If you mean having one target call another, the <call> task
can be considered a type of function invocation. One target can define
a bunch of properties and then use <call> to invoke a second target.
...
Other questions:
3. Is there still a development on nant? Is further development needed
or is the tool finalized? Should I migrate to MSBuild? Have you already?
When is the final release released?
There is still plenty of NAnt development. It's not finalized, though
I'm starting to think that 0.85 should be declared done and renumbered
as 1.0. However, I'm not a NAnt developer, and it's not my decision.
As for using MSBuild, personally I think it's far more likely that the
politics of your organization will impact that decision than the
technical differences. This includes the decision to move from Visual
Studio 2003 to Visual Studio 2005. If you're just starting, and if
you're already using just Visual Studio .Net 2005 with no 2003, then
you're better off with MSBuild. I don't think MSBuild handles 2003
solution or project files, so that favors NAnt. Either way, it's
always possible (in theory) to bypass the project files and call the
compilers and other tools directly. Finally, if you trip over some of
the inconsistencies in NAnt between what the <solution> task does and
what Visual Studio does, and if absolute consistency between the two is
required, you may be better off with MSBuild. (I don't think any of the
inconsistencies are conscious decisions to diverge from Visual Studio;
they're either bugs or things that have yet to be implemented. I have
no problems using the NAnt <solution> task.)
It's also possible to use both. I have a hybrid build system, where
NAnt calls Ant to build the Java pieces, and the UNIX builds are all
reasonably well-structured bash, with GNU make at the project level.
...
5. What is about Ant? Can I do the same with Ant by now? Is it an
alternative for Nant? Especially if I don't use it for .NET software?
If you're not doing .Net development, then Ant is a viable option,
especially if you know Java and expect to write custom tasks. The only
thing I can think of that isn't .Net that NAnt can do while Ant cannot
is straight C++ development. Even there, C++ in NAnt has taken a back
seat to C# and VB.Net.
Sorry if the questions are stupid. I'm still a newbie and I would like
to improve the use of nant somehow.
None of the questions were stupid. But the bottom line, with any new
tool, is that you have to actually use it for a while to appreciate it.
Gary
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
