[nant-dev] For review - 0.8.3 rc1 release notes
0.8.3rc1 release notes (plain text format)
Please review and post your comments to the mailing list. I'm starting the
release process tonight with the 0.8.3 branch. It's a bit more detailed than
previous logs, but I think I got all the significant changes that might
impact an unwary user.
John C Barstow
USER-VISIBLE CHANGES
- NAntContrib is now distributed with NAnt.
To better support the frequently-used NAntContrib extensions, the library
is now distributed as part of the NAnt release.
- Preliminary Linux support with Mono 0.25.
This is the first release with Linux support, so please report any issues
you encounter. The next release will be fully tested and documented on boht
Linux and Windows.
- New Tasks
See the user documentation for usage details.
) cvs: Performs various CVS tasks.
) cvs-checkout: Checkout source from CVS.
) cvs-update: Update source from CVS.
) mcs: Compile using the mono compiler. Note that the functionality of
this task will be likely be incorporated into the csc task.
) solution: compile .sln directly. In most cases, this means you no
longer have to preprocess a solution with the slingshot tool.
- Changed Tasks
See the section below for details.
- Fileset References
You can now define a named fileset and refer to it anywhere a fileset is
used.
DEVELOPER-VISIBLE CHANGES
- Namespace changes
There have been major code reorganizations since the last release.
) SourceForge is no longer part of the NAnt namespaces.
) Split classes up into Tasks and Types.
) Task assemblies now have their own namespaces.
) Removed Msft prefix from base classes.
- Logging framework changed. The logging framework is now based on
Log4Net.
) Refactored NAnt (build) logging system : moved to an event driver
logging system, and allow thresholds to be set. The build outcome is now
completely handled by the loggers.
) Replaced the LogListener with an IBuildLogger interface for loggers
and an IBuildListener interface for build listeners.
) The ConsoleLogger is replaced by a DefaultLogger, which always logs to
the console, and which can also be configured to log to a file (using the
-logfile option).
) The static Log class is removed and replaced by instance methods on
the Project and Task classes. These instance methods actually fire events
that get handled by the build logger and buid listeners.
) Added a Level enum that is used to assign a priority (level) to a
message. This allows messages to be filtered on their priority.
) Added a strongly typed collection for the build listeners.
) Updated all existing logging statements to use the new logging system
instead of the static Log class. Assigned levels to the existing logging
statements.
) Added MailLogger that can be used to send the build results as an
email, see xml docs for how its to be configured
- Many, many style/structure/documentation fixes. More that are worth
listing here.
- Fixed NUnit2 support for filesets.
- Prevent warnings for using obsolete methods to allow NDoc Document.Nant
to build on .NET 1.1 runtime.
- Nightly.xml No longer depends on NAntContrib tasks.
- Moved mail task and test back into core as its working fine on linux
now.
- New attribute-driven command-line parser.
SLINGSHOT CHANGES
- Fixed defect: slingshot now handles the fact that sln/proj files might
have a disparate list of configurations.
- Fixed defect: if a configuration name contains whitespace, it is
referenced in the slingshot output .build file w/ hyphens replacing
whitespace, as nant can't deal w/ blanks in target names.
- Added flexibility: the Clean.* targets are generated from the existing
list of configurations, in addition to the only hardcoded DebugClean and
ReleaseClean targets.
- Fixed limitation around references: references that are set to Copy
Local=true get copied to the build directory before compilation. otherwise,
the reference paths are explicitly listed in referencesincludes.
- New parameter: (per a suggestion from a user who replied to my notice of
impending changes) starting slingshot with the parameter replacerefs=...
triggers the reference paths to be replaced with the name of the build
configuration. for example, if projB references
d:\proj\projA\bin\Debug\projA.dll, when you slingshot projB with parameter
replacerefs=Debug, the reference to projA will look like
d:\proj\projA\bin\${slingshot.config}\projA.dll. when you then build
projB.build for config Release, the projA reference will look like this:
d:\proj\projA\bin\Release\projA.dll.
- Added support for WarningLevel (now that it's available in nant)
COMMAND-LINE CLIENT CHANGES
- Changed target back to the default argument.
- Moved company information (http://nant.sourceforge.net) from help text
to logo banner
- Added support for running default.build if
[nant-dev] Just a suggestion...
Hi all,
right now, the nunit2 task takes the following
form:
nunit2
test assemblyname=${build.dir}/bin/MyModule.Tests.dll/
/nunit2
The task above doesn't test an 'assembly', but a 'module'.
One can create single-module assemblies or multi-module
assemblies, but a test task always tests a module.
So, I would suggest to rename the assemblyname property to
module:
nunit2
test module=${build.dir}/bin/MyModule.Tests.dll/
/nunit2
What do you think about that?
Gius_.
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Still problems with the if and ifnot tasks
The unit test for uptodatefile/comparefile is wrong. It reverses the sense. I had this fixed locally on my machine once, but I've since lost the changes after the big reorg. It's relatively easy to fix the unit test, then fix the code. - Ants | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On | Behalf Of Giuseppe Greco | Sent: Tuesday, 08 July, 2003 21:39 | To: [EMAIL PROTECTED] | Subject: [nant-dev] Still problems with the if and ifnot tasks | | | Hi all, | | My be I'm wrong... but I think there is an | issue with the if and ifnot task. | | Look at the following task: | | ifnot |uptodatefile=myImage.png |comparefile=myImage.xcf |exec | program=xcftoall | commandline=--png myImage.xcf myImage.png/ | /ifnot | | If I've understood the documentation right, the task | above executes the exec task if and only if myImage.png | is older than myImage.xcf, right? | | But this is not the case. To regenerate myImage.png after | myImage.xcf has been modified, I've to rewrite the task | above like this: | | ifnot |uptodatefile=myImage.xcf |comparefile=myImage.png |exec | program=xcftoall | commandline=--png myImage.xcf myImage.png/ | /ifnot | | I checked out NAnt from CVS last Saturday, so it should | be new enough... | | Any idea? | | Gius_ | | | | --- | This SF.Net email sponsored by: Parasoft | Error proof Web apps, automate testing more. | Download eval WebKing and get a free book. | www.parasoft.com/bulletproofapps | ___ | nant-developers mailing list [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/nant-developers | --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Just a suggestion...
What's your definition of module versus assembly ?
- Ants
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On
| Behalf Of Giuseppe Greco
| Sent: Wednesday, 09 July, 2003 00:57
| To: [EMAIL PROTECTED]
| Subject: [nant-dev] Just a suggestion...
|
|
| Hi all,
|
| right now, the nunit2 task takes the following
| form:
|
| nunit2
|test assemblyname=${build.dir}/bin/MyModule.Tests.dll/
| /nunit2
|
| The task above doesn't test an 'assembly', but a 'module'.
| One can create single-module assemblies or multi-module
| assemblies, but a test task always tests a module.
|
| So, I would suggest to rename the assemblyname property to
| module:
|
| nunit2
|test module=${build.dir}/bin/MyModule.Tests.dll/
| /nunit2
|
| What do you think about that?
|
| Gius_.
|
|
|
| ---
| This SF.Net email sponsored by: Parasoft
| Error proof Web apps, automate testing more.
| Download eval WebKing and get a free book.
| www.parasoft.com/bulletproofapps
| ___
| nant-developers mailing list [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/nant-developers
|
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Just a suggestion...
To be honest the occurance of multi module assemblies is low enough that
I think most users will find 'assembly' a more meaningful identifier
than 'module'.
the Assembly.LoadFrom() method which loads a specific file off disk
calls that file paramater 'assemblyFile' not 'moduleFile'. So I think we
are safe enough using assembly.
Ian
Anthony LoveFrancisco wrote:
What's your definition of module versus assembly ?
- Ants
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On
| Behalf Of Giuseppe Greco
| Sent: Wednesday, 09 July, 2003 00:57
| To: [EMAIL PROTECTED]
| Subject: [nant-dev] Just a suggestion...
|
|
| Hi all,
|
| right now, the nunit2 task takes the following
| form:
|
| nunit2
|test assemblyname=${build.dir}/bin/MyModule.Tests.dll/
| /nunit2
|
| The task above doesn't test an 'assembly', but a 'module'.
| One can create single-module assemblies or multi-module
| assemblies, but a test task always tests a module.
|
| So, I would suggest to rename the assemblyname property to
| module:
|
| nunit2
|test module=${build.dir}/bin/MyModule.Tests.dll/
| /nunit2
|
| What do you think about that?
|
| Gius_.
|
|
|
| ---
| This SF.Net email sponsored by: Parasoft
| Error proof Web apps, automate testing more.
| Download eval WebKing and get a free book.
| www.parasoft.com/bulletproofapps
| ___
| nant-developers mailing list [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/nant-developers
|
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Just a suggestion...
-- Original Message --
From: Ian MacLean [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: 'Giuseppe Greco' [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [nant-dev] Just a suggestion...
Date: Thu, 10 Jul 2003 10:58:16 +0900
To be honest the occurance of multi module assemblies is low enough that
I think most users will find 'assembly' a more meaningful identifier
than 'module'.
the Assembly.LoadFrom() method which loads a specific file off disk
calls that file paramater 'assemblyFile' not 'moduleFile'. So I think we
are safe enough using assembly.
Ian
Anthony LoveFrancisco wrote:
What's your definition of module versus assembly ?
A module, is a single application component, while
an assembly encloses all the modules (or component) that
form an application. When we run the test case, we are
actually testing a single application component, not
the whole application (assembly).
Gius_.
- Ants
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On
| Behalf Of Giuseppe Greco
| Sent: Wednesday, 09 July, 2003 00:57
| To: [EMAIL PROTECTED]
| Subject: [nant-dev] Just a suggestion...
|
|
| Hi all,
|
| right now, the nunit2 task takes the following
| form:
|
| nunit2
|test assemblyname=${build.dir}/bin/MyModule.Tests.dll/
| /nunit2
|
| The task above doesn't test an 'assembly', but a 'module'.
| One can create single-module assemblies or multi-module
| assemblies, but a test task always tests a module.
|
| So, I would suggest to rename the assemblyname property to
| module:
|
| nunit2
|test module=${build.dir}/bin/MyModule.Tests.dll/
| /nunit2
|
| What do you think about that?
|
| Gius_.
|
|
|
| ---
| This SF.Net email sponsored by: Parasoft
| Error proof Web apps, automate testing more.
| Download eval WebKing and get a free book.
| www.parasoft.com/bulletproofapps
| ___
| nant-developers mailing list [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/nant-developers
|
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing more.
Download eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
