RE: [Fwd: Ready to tackle next release]
If you are getting ready for a new release, I have a bunch of patches I would
love to see added to NAnt. I would be willing to work with everyone as much
as needed, to see that the changes make it into the release; or some variation
of them - that is, if they are accepted.
Here is a run down of our current changes to NAnt:
I have mentioned this one previously; and it involves adding an "options"
property to CompilerBase.cs. The original post had no subject and came out
garbled (sorry about that), though I have filed it under RFE "[811931] -
Adding an "options" property to CompilerBase.cs", where you can read about the
change in more detail.
Another change we made was to allow passing of "parameters" as properties to
other NAnt scripts via the "nant" task. This works really well and avoids
having to using the "inheritall" attribute (which can be overkill -
particularly if you have scripts that call themselves externally...). You can
think of this feature as adding support for the "-D:" options of nant.exe
The syntax looks like this:
<nant buildfile="somefile" inheritall="false" target="sometarget">
<defines>
<property name="buildtarget" value="${script.build.target}" />
<property name="copytarget" value="${script.copy.target}" />
</defines>
</nant>
The "defines" are created as properties and accessible only from the invoked
NAnt script as if they were passed with "-D:". Their values are evaluated at
the time just before the new script is invoked. Note: You can still use
the "inheritall" attribute as well, though anything defined will override
anything inherited if there is a name collision. The patch for this change
is straightforward and simple. The only part left to do is handling all the
NAnt location stuff with properties, which I am not too sure about (currently,
I set this to unknown), though I'm sure someone on the list can enlighten me.
Our next change is the most extensive but it fixes a long out-standing issue
with NAnt. Basically, we did a rewrite on how NAnt handles RESX files.
Currently NAnt has the following problems:
1.) The regular expressions for determining the namespace are poor and
are easily confused by comments (that have the word namespace in them, for
example "// is located in the foo namespace").
2.) The regular expressions used by different languages are executed on
all the source files. For example, when compiling a "*.cs" file the regular
expressions for capitalized namespace lookup (I guess for VB) is executed even
when it should not; this is bad, as it picks up false positives and increase
the chance of error.
3.) The biggest problem is that NAnt assumes the filename (of the source
file) is the name of the class that the RESX should be associated too. This
issue killed our use of NAnt (until we fixed it), as our filenames do not
match the "Form" class within them; Visual Studio does not have a problem with
this.
Our patch fixes all these issues. For number 3, we actually added additional
regular expression that extract the correct class name from the source instead
of assuming it is the same as the file. This works extremely well, mainly
because Visual Studio forces the Form/Control classes to always be the first
class in the file (now you know why they do this, it seems that VS needs to do
all this work as well...).
The way we implemented it was by making a class like this:
protected struct ResourceLinkage {
private string _namespaceName;
private string _className;
public ResourceLinkage(string namespaceName, string className) {
_namespaceName = namespaceName.Trim();
_className = className.Trim();
}
public override string ToString() {
return ...; // Outputs path to resources
}
public string NamespaceName {
get { return _namespaceName; }
set { _namespaceName = value; }
}
public string ClassName {
get { return _className; }
set { _className = value; }
}
}
...to store and keep track of this information. Then we changed the function
that normally returns just a string, to this:
protected virtual ResourceLinkage GetFormResourceLinkage(string resxPath) {}
The regular expressions we use are:
Regex matchNamespaceRE = new Regex(@"^\s*namespace ((\w+.)*)");
Regex matchNamespaceCapsRE = new Regex(@"^\s*Namespace ((\w+.)*)");
Regex matchClassNameRE = new Regex(@"^([\s\w]*\s)?class\s+(?<class>\w+)");
Anyway, that is the basic gist of it.
There are some issues yet to be resolved. For one, I know nothing about VB
(okay, I know some, but very little), and have not written the Regex patterns
for it. I am also not sure that thee new "class-name" Regex use successfully
for "*.cs" files will work for J#.
The Regex patterns can be improved further (though these are problems with the
current version of NAnt as well).
/*
namespace test
class something here
*/
namespace foo {
namespace bar {
class foo : Form { }
}
}
The above examples can still break things (though are not that common in
practice). Fortunately, nether of these are that hard to fix and I would be
willing to do the work. With these improvements, NAnt would work exactly as
VS does (well..., as far as I can tell.)
Lastly, we made a few tweaks to the "cl" task, but they were minor; like
moving the "options" attribute to write the parameters latter in the response-
file so it can be used to override undesirable NAnt settings.
Anyway, if you want to add any of these enhancements to NAnt please let me
know. I would be more then happy to work on them and could turn around
changes very fast as I can dedicate my full time to these issues.
James.
Quoting [EMAIL PROTECTED]:
> It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1
> as the default. Ian - do you think it would be possible to get the
> ReplaceTask into the core if I can make it more robust?
>
> ----------------------------------------
> - Mitch Denny
> - [EMAIL PROTECTED]
> - http://www.monash.net
> - +61 (414) 610141
> -
>
> > -----Original Message-----
> > From: Ian MacLean [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 03, 2003 2:31 PM
> > To: [EMAIL PROTECTED]
> > Subject: [nant-dev] [Fwd: Ready to tackle next release]
> >
> >
> >
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
