Re: [nant-dev] Problem with the resgen task on Linux
Hi Giuseppe,
I looked at the code of the resgen task, and apparently it's not being
executed on the mono runtime right now.
The following comment is in the UsesRuntimeEngine property :
// TO-DO : uncomment this when monoresgen no longer crashes when run with
the mono runtime.
I think that comment was put there by Ian, but I haven't checked this.
Can you uncomment the code in in Resgen.UsesRuntimeEngine and try again ?
Gert
- Original Message -
From: Giuseppe Greco [EMAIL PROTECTED]
To: NAnt Developers [EMAIL PROTECTED]
Sent: Saturday, June 28, 2003 11:44 AM
Subject: [nant-dev] Problem with the resgen task on Linux
Hi all,
I've target like this:
target
name=build
description=Builds resource binaries for de-DE culture
mkdir
dir=${build.dir}/bin/${culture}
failonerror=false/
resgen
input=${assembly}.resx
output=${assembly}.${culture}.resources
todir=${build.dir}/bin/${culture}/
al
target=lib
culture=${culture}
output=${build.dir}/bin/${culture}/${assembly}.resources.dll
sources basedir=${build.dir}/bin/${culture}
includes name=*.resources/
/sources
/al
/target
The target above just generates a .resources file and the
related satellite resource assembly DLL.
It works on Windows, but it doesn't on Linux!
monoresgen complies like this:
/home/genius/projects/gekkota/src/Gekkota.Core/de-DE/default.build(44,60):
resgen task/usr/local/bin/monoresgen.exe failed to start.
Cannot find the specified file
The *.resx file to compile is there and error free (otherwise it
wouldn't have compiled on Windows)... Does anybody know more on this?
Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Problem with the resgen task on Linux
Hi Gert,
On Sat, 2003-06-28 at 13:48, Gert Driesen wrote:
Hi Giuseppe,
I looked at the code of the resgen task, and apparently it's not being
executed on the mono runtime right now.
The following comment is in the UsesRuntimeEngine property :
// TO-DO : uncomment this when monoresgen no longer crashes when run with
the mono runtime.
I think that comment was put there by Ian, but I haven't checked this.
Can you uncomment the code in in Resgen.UsesRuntimeEngine and try again ?
I've tried it, but it doesn't work at all.
This is the error message:
Error: Exception has been thrown by the target of an invocation.
Total time: 0 seconds.
May be that's why Ian commented out lines from 130 to 135 in
ResGenTask.cs ...
Gius_.
Gert
- Original Message -
From: Giuseppe Greco [EMAIL PROTECTED]
To: NAnt Developers [EMAIL PROTECTED]
Sent: Saturday, June 28, 2003 11:44 AM
Subject: [nant-dev] Problem with the resgen task on Linux
Hi all,
I've target like this:
target
name=build
description=Builds resource binaries for de-DE culture
mkdir
dir=${build.dir}/bin/${culture}
failonerror=false/
resgen
input=${assembly}.resx
output=${assembly}.${culture}.resources
todir=${build.dir}/bin/${culture}/
al
target=lib
culture=${culture}
output=${build.dir}/bin/${culture}/${assembly}.resources.dll
sources basedir=${build.dir}/bin/${culture}
includes name=*.resources/
/sources
/al
/target
The target above just generates a .resources file and the
related satellite resource assembly DLL.
It works on Windows, but it doesn't on Linux!
monoresgen complies like this:
/home/genius/projects/gekkota/src/Gekkota.Core/de-DE/default.build(44,60):
resgen task/usr/local/bin/monoresgen.exe failed to start.
Cannot find the specified file
The *.resx file to compile is there and error free (otherwise it
wouldn't have compiled on Windows)... Does anybody know more on this?
Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] fileset references
Its definately in cvs. I've done a clean check out into a seperate directory and the example below works fine. Are you seeing errors ? What isn't working ? Ian Ian, On Tue, 2003-06-24 at 11:35, Ian MacLean wrote: fileset references are done. I still need to add some unit tests and polish a few things but its all working. try somthing like the following : fileset id=foo includes name=*.*/ /fileset copy todir=. overwrite=true fileset refid=foo/ /copy There is now a general framework for referencable types. Its only implemented for filesets right now. Is that on CVS? It doesn't seem so... Gius_. Ian --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] fileset references
On Sat, 2003-06-28 at 16:10, Ian MacLean wrote: Its definately in cvs. I've done a clean check out into a seperate directory and the example below works fine. Are you seeing errors ? What isn't working ? NAnt simply says Unknown task fileset. Gius_. Ian Ian, On Tue, 2003-06-24 at 11:35, Ian MacLean wrote: fileset references are done. I still need to add some unit tests and polish a few things but its all working. try somthing like the following : fileset id=foo includes name=*.*/ /fileset copy todir=. overwrite=true fileset refid=foo/ /copy There is now a general framework for referencable types. Its only implemented for filesets right now. Is that on CVS? It doesn't seem so... Gius_. Ian --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)76 390 60 32 email: [EMAIL PROTECTED] web:www.agamura.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] fileset references
On Sat, 2003-06-28 at 16:15, Ian MacLean wrote: windows or linux ? - is your fileset definition at the project level ? fileset definitions at target level are not supported right now. A-ha, that's the problem... I'm trying to use fileset definitions at target level... Gius_. Ian On Sat, 2003-06-28 at 16:10, Ian MacLean wrote: Its definately in cvs. I've done a clean check out into a seperate directory and the example below works fine. Are you seeing errors ? What isn't working ? NAnt simply says Unknown task fileset. Gius_. Ian Ian, On Tue, 2003-06-24 at 11:35, Ian MacLean wrote: fileset references are done. I still need to add some unit tests and polish a few things but its all working. try somthing like the following : fileset id=foo includes name=*.*/ /fileset copy todir=. overwrite=true fileset refid=foo/ /copy There is now a general framework for referencable types. Its only implemented for filesets right now. Is that on CVS? It doesn't seem so... Gius_. Ian --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)76 390 60 32 email: [EMAIL PROTECTED] web:www.agamura.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Problem with the resgen task on Linux
Guis,
can you run with -verbose. Grab the commandline thats generated and try
it in a shell window. ie see if the same failure occurs when running
monoresgen by itself. If not can you post the full output generated by
nant - including stack trace.
Ian
Hi Gert,
On Sat, 2003-06-28 at 13:48, Gert Driesen wrote:
Hi Giuseppe,
I looked at the code of the resgen task, and apparently it's not being
executed on the mono runtime right now.
The following comment is in the UsesRuntimeEngine property :
// TO-DO : uncomment this when monoresgen no longer crashes when run with
the mono runtime.
I think that comment was put there by Ian, but I haven't checked this.
Can you uncomment the code in in Resgen.UsesRuntimeEngine and try again ?
I've tried it, but it doesn't work at all.
This is the error message:
Error: Exception has been thrown by the target of an invocation.
Total time: 0 seconds.
May be that's why Ian commented out lines from 130 to 135 in
ResGenTask.cs ...
Gius_.
Gert
- Original Message -
From: Giuseppe Greco [EMAIL PROTECTED]
To: NAnt Developers [EMAIL PROTECTED]
Sent: Saturday, June 28, 2003 11:44 AM
Subject: [nant-dev] Problem with the resgen task on Linux
Hi all,
I've target like this:
target
name=build
description=Builds resource binaries for de-DE culture
mkdir
dir=${build.dir}/bin/${culture}
failonerror=false/
resgen
input=${assembly}.resx
output=${assembly}.${culture}.resources
todir=${build.dir}/bin/${culture}/
al
target=lib
culture=${culture}
output=${build.dir}/bin/${culture}/${assembly}.resources.dll
sources basedir=${build.dir}/bin/${culture}
includes name=*.resources/
/sources
/al
/target
The target above just generates a .resources file and the
related satellite resource assembly DLL.
It works on Windows, but it doesn't on Linux!
monoresgen complies like this:
/home/genius/projects/gekkota/src/Gekkota.Core/de-DE/default.build(44,60):
resgen task/usr/local/bin/monoresgen.exe failed to start.
Cannot find the specified file
The *.resx file to compile is there and error free (otherwise it
wouldn't have compiled on Windows)... Does anybody know more on this?
Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] fileset references
cool. I'm just adding support for target level now. Its pretty straightforward. Ian On Sat, 2003-06-28 at 16:15, Ian MacLean wrote: windows or linux ? - is your fileset definition at the project level ? fileset definitions at target level are not supported right now. A-ha, that's the problem... I'm trying to use fileset definitions at target level... Gius_. Ian On Sat, 2003-06-28 at 16:10, Ian MacLean wrote: Its definately in cvs. I've done a clean check out into a seperate directory and the example below works fine. Are you seeing errors ? What isn't working ? NAnt simply says Unknown task fileset. Gius_. Ian Ian, On Tue, 2003-06-24 at 11:35, Ian MacLean wrote: fileset references are done. I still need to add some unit tests and polish a few things but its all working. try somthing like the following : fileset id=foo includes name=*.*/ /fileset copy todir=. overwrite=true fileset refid=foo/ /copy There is now a general framework for referencable types. Its only implemented for filesets right now. Is that on CVS? It doesn't seem so... Gius_. Ian --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Problem with the resgen task on Linux
On Sat, 2003-06-28 at 16:22, Ian MacLean wrote:
Guis,
can you run with -verbose. Grab the commandline thats generated and try
it in a shell window. ie see if the same failure occurs when running
monoresgen by itself. If not can you post the full output generated by
nant - including stack trace.
No, monoresgen doesn't work... I'll post this to the Mono list.
Gius_.
Ian
Hi Gert,
On Sat, 2003-06-28 at 13:48, Gert Driesen wrote:
Hi Giuseppe,
I looked at the code of the resgen task, and apparently it's not being
executed on the mono runtime right now.
The following comment is in the UsesRuntimeEngine property :
// TO-DO : uncomment this when monoresgen no longer crashes when run with
the mono runtime.
I think that comment was put there by Ian, but I haven't checked this.
Can you uncomment the code in in Resgen.UsesRuntimeEngine and try again ?
I've tried it, but it doesn't work at all.
This is the error message:
Error: Exception has been thrown by the target of an invocation.
Total time: 0 seconds.
May be that's why Ian commented out lines from 130 to 135 in
ResGenTask.cs ...
Gius_.
Gert
- Original Message -
From: Giuseppe Greco [EMAIL PROTECTED]
To: NAnt Developers [EMAIL PROTECTED]
Sent: Saturday, June 28, 2003 11:44 AM
Subject: [nant-dev] Problem with the resgen task on Linux
Hi all,
I've target like this:
target
name=build
description=Builds resource binaries for de-DE culture
mkdir
dir=${build.dir}/bin/${culture}
failonerror=false/
resgen
input=${assembly}.resx
output=${assembly}.${culture}.resources
todir=${build.dir}/bin/${culture}/
al
target=lib
culture=${culture}
output=${build.dir}/bin/${culture}/${assembly}.resources.dll
sources basedir=${build.dir}/bin/${culture}
includes name=*.resources/
/sources
/al
/target
The target above just generates a .resources file and the
related satellite resource assembly DLL.
It works on Windows, but it doesn't on Linux!
monoresgen complies like this:
/home/genius/projects/gekkota/src/Gekkota.Core/de-DE/default.build(44,60):
resgen task/usr/local/bin/monoresgen.exe failed to start.
Cannot find the specified file
The *.resx file to compile is there and error free (otherwise it
wouldn't have compiled on Windows)... Does anybody know more on this?
Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Anonymous CVS
Hi all, DocBook source files of the documents Building Projects With NAnt and C# Coding Guidelines can be checked out from anonymous CVS: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/technotes co building-projects-with-nant csharp-coding-guidelines They have been compiled on Linux using xsltproc as XSLT processor and Apache FOP as FO processor (I plan to switch from FOP to xmlroff very soon). If you intend to compile them on Windows, you have to adjust the build files depending on the tools you are using. Software requirements and build instructions can be found in the file INSTALL, which is part of the distribution. Gius_. Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)76 390 60 32 email: [EMAIL PROTECTED] web:www.agamura.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Ian I am concerned about the friction NAnt users are experiencing trying to contribute and in general use the NAntContrib tasks: http://www.iunknown.com/000278.html I would love to help clean up NAntContrib. I have some recent experience from updating the StarTeam tasks. I will take a look at the items Mike listed and see what I can do. If anyone can relay motes of wisdom please jump in. Kevin Miller --- From: Mike Roberts [EMAIL PROTECTED] Updating Nant-Contrib to latest Nant 2003-06-25 14:56 I spent a couple of hours looking at updating Nant-Contrb last night to compile against the latest NAnt, and realised its a lot more than just changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. Other updates since Nant 0.8.2 that effect Nant-Contrib include: - Logging has completely changed - Log Listeners have disappeared, so FileLogListener and the RecordTask need to change significantly - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') - Some stuff has moved to Nant.Core.Types - OptionCollection stuff seems to have completely changed - and more (I think) In light of this, the fact that I don't know Nant-Contrib very well, and also that there aren't a significant amount of tests, I'm now reluctant to update the whole of Nant-Contrib. I'm only using the mkiisdir task, so can just update that locally.. However, I'm going to bold now and give my opinion which the project leads are more than free to completely disregard. :) I don't really understand why Nant-Contrib and Nant are 2 separate projects. I can see the value in having separation to some extent (e.g. downloadable binaries, so that users don't have to download a bunch of tasks that they don't want), but on the other hand complete separation leads to (a) confusion in the user community and (b) the kind of situation that currently exists where there are significant differences between the 2 trees. I personally think it would be valuable, therefore, if the following happened: 1 - As a goal, the Nant-Contrib project should be phased out 2 - All the work (that is going to continue to live on) from Nant-Contrib should be (task-by-task) brought into the Nant project, maybe under a separate directory called 'optional-tasks'[a] 3 - The Nant buildfile should compile both the NAnt Core, the existing extra tasks and the 'optional-tasks' so that the latter of these don't get out of sync with changes to the core. 4 - ... a result of which would be the tasks imported from Nant-Contrib would also be updated to fit in with latest NAnt [a] - I actually think that some of the (smaller) tasks from Nant-Contrib maybe better off in the main Nant download. Perhaps the NAnt committee would want to think about each task on a case-by-case basis. Of course, I'm a newbie round here, and there are probably very good reasons for the separation of the projects and I'm just being presumptuous to suggest such a plan of action. :) Cheers, Mike --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET.
Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
How do you propose to deal with the NAntContrib sources ? will they be moved into /src/NAnt.Optional and /tests/NAnt.Optional or will they be integrated into the current namespace structure ? I would still like to get rid of needing a COM interop assembly for SourceSafe (and if possible also for StarTeam, don't know if that's possible though). Can't we create a wrapper for the vss commandline tool ? Gert On Sat, 2003-06-28 at 18:53, Ian MacLean wrote: OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Ian I am concerned about the friction NAnt users are experiencing trying to contribute and in general use the NAntContrib tasks: http://www.iunknown.com/000278.html I would love to help clean up NAntContrib. I have some recent experience from updating the StarTeam tasks. I will take a look at the items Mike listed and see what I can do. If anyone can relay motes of wisdom please jump in. Kevin Miller --- From: Mike Roberts [EMAIL PROTECTED] Updating Nant-Contrib to latest Nant 2003-06-25 14:56 I spent a couple of hours looking at updating Nant-Contrb last night to compile against the latest NAnt, and realised its a lot more than just changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. Other updates since Nant 0.8.2 that effect Nant-Contrib include: - Logging has completely changed - Log Listeners have disappeared, so FileLogListener and the RecordTask need to change significantly - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') - Some stuff has moved to Nant.Core.Types - OptionCollection stuff seems to have completely changed - and more (I think) In light of this, the fact that I don't know Nant-Contrib very well, and also that there aren't a significant amount of tests, I'm now reluctant to update the whole of Nant-Contrib. I'm only using the mkiisdir task, so can just update that locally.. However, I'm going to bold now and give my opinion which the project leads are more than free to completely disregard. :) I don't really understand why Nant-Contrib and Nant are 2 separate projects. I can see the value in having separation to some extent (e.g. downloadable binaries, so that users don't have to download a bunch of tasks that they don't want), but on the other hand complete separation leads to (a) confusion in the user community and (b) the kind of situation that currently exists where there are significant differences between the 2 trees. I personally think it would be valuable, therefore, if the following happened: 1 - As a goal, the Nant-Contrib project should be phased out 2 - All the work (that is going to continue to live on) from Nant-Contrib should be (task-by-task) brought into the Nant project, maybe under a separate directory called 'optional-tasks'[a] 3 - The Nant buildfile should compile both the NAnt Core, the existing extra tasks and the 'optional-tasks' so that the latter of these don't get out of sync with changes to the core. 4 - ... a result of which would be the tasks imported from Nant-Contrib would also be updated to fit in with latest NAnt [a] - I actually think that some of the (smaller) tasks from Nant-Contrib maybe better off in the main Nant download. Perhaps the NAnt committee would want to think about each task on a case-by-case basis. Of course, I'm a newbie round here, and there are probably very good reasons for the separation of the projects and I'm just being presumptuous to suggest such a plan of action. :) Cheers, Mike --- This SF.Net email is sponsored by: INetU Attention Web
RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
Ian, OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Why optional? If we're gonna move them, you might as well move them right. For example, some Nant tasks should go into the main Nant builds... Things like GAC and XSD are fairly common DotNet development operations (I don't know what criteria you guys are using for separating the tasks, though, so I may be mistaken here). rant That said, I'd like to take the opportunity to vent something that has been nagging me for a while: All the continous Nant restructuring. Granted, some good things have gone on, and the base is much clear. However, I'm going to be brutally honest here: Even though no 1.0 release of nant has ever been done, it has been used by people to build *real* systems for a really long time now. And you know what? Everyone I've met using Nant has created their own tasks to make their builds more powerful/simple/easier, and that's a *good* thing. However, all the restructuring going on keeps breaking their tasks code, and that ain't nice. Hell, we can't even keep NAntContrib compiling and that's supposed to be *the* nant partner-project. How do you expect people to keep up with all the changes you guys do? (and I'll be even more brutal here and say many of those changes have been fairly gratuitous, with very, very little added value). My big point is that many of the changes were done with little or no regard to the impact they might have on code outside the actual nant code base, and that's a problem now. One I personally consider a serious one. The sad part is, many of them could've been done in a gradual maner, deprecating and wrapping things so that people could slowly migrate things over. Things like the logging infrastructure, Option sets, etc, could've been approach in such a way that they didn't force people into having to change perfectly working code all at once, for example. If you want people to use nant effectively, and be able to take advantage of what new builds of Nant offers easily, you need to start taking into consideration just how easy is going to migrate to a new build, and that takes far more than simply ensuring the .build files are valid. Just something to think about. /rant -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] RE: NAntContrib update was ( Updating Nant-Contrib to latest Nant)
+1 as if I should have any say in the matter ;) Ian, this is excellent. You did everything I had dreamed would happen with NAntContrib and more. I think this is a good move. I was just sitting down to start looking at what changes were necessary and was happy to see this post. I look forward to testing the .zip against our builds. Re: 1) What if there were two tiers optional tasks based on their maturity. Experimental - completed tasks being evaluated and considered for inclusion with stable Stable - unit tested mother approved guaranteed to build against current tree 2) I agree source history is always valuable Kevin -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2003 10:53 AM To: Miller, Kevin Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: NAntContrib update was ( Updating Nant-Contrib to latest Nant) OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Ian I am concerned about the friction NAnt users are experiencing trying to contribute and in general use the NAntContrib tasks: http://www.iunknown.com/000278.html I would love to help clean up NAntContrib. I have some recent experience from updating the StarTeam tasks. I will take a look at the items Mike listed and see what I can do. If anyone can relay motes of wisdom please jump in. Kevin Miller --- From: Mike Roberts [EMAIL PROTECTED] Updating Nant-Contrib to latest Nant 2003-06-25 14:56 I spent a couple of hours looking at updating Nant-Contrb last night to compile against the latest NAnt, and realised its a lot more than just changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. Other updates since Nant 0.8.2 that effect Nant-Contrib include: - Logging has completely changed - Log Listeners have disappeared, so FileLogListener and the RecordTask need to change significantly - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') - Some stuff has moved to Nant.Core.Types - OptionCollection stuff seems to have completely changed - and more (I think) In light of this, the fact that I don't know Nant-Contrib very well, and also that there aren't a significant amount of tests, I'm now reluctant to update the whole of Nant-Contrib. I'm only using the mkiisdir task, so can just update that locally.. However, I'm going to bold now and give my opinion which the project leads are more than free to completely disregard. :) I don't really understand why Nant-Contrib and Nant are 2 separate projects. I can see the value in having separation to some extent (e.g. downloadable binaries, so that users don't have to download a bunch of tasks that they don't want), but on the other hand complete separation leads to (a) confusion in the user community and (b) the kind of situation that currently exists where there are significant differences between the 2 trees. I personally think it would be valuable, therefore, if the following happened: 1 - As a goal, the Nant-Contrib project should be phased out 2 - All the work (that is going to continue to live on) from Nant-Contrib should be (task-by-task) brought into the Nant project, maybe under a separate directory called 'optional-tasks'[a] 3 - The Nant buildfile should compile both the NAnt Core, the existing extra tasks and the 'optional-tasks' so that the latter of these don't get out of sync with changes to the core. 4 - ... a result of which would be the tasks imported from Nant-Contrib would also be updated to fit in with latest NAnt [a] - I actually think that some of the (smaller) tasks from Nant-Contrib maybe better off in the main Nant download. Perhaps the NAnt committee would want to think about each task on a
RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
Not sure about VSS. Unfortunately the COM Interop for StarTeam is very necessary as it is the only programmatic interface to their server. Maybe I missed the point of the desire to be rid of it. The StarTeam SDK now has an official .NET interop assembly distributed with their 5.2 SDK. When the new contrib stuff stabilizes I will update the binary and build file if necessary. Is anyone using the StarTeam tasks in NantContrib? -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2003 1:40 PM To: Ian MacLean Cc: Miller, Kevin; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant) How do you propose to deal with the NAntContrib sources ? will they be moved into /src/NAnt.Optional and /tests/NAnt.Optional or will they be integrated into the current namespace structure ? I would still like to get rid of needing a COM interop assembly for SourceSafe (and if possible also for StarTeam, don't know if that's possible though). Can't we create a wrapper for the vss commandline tool ? Gert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] RE: NAntContrib update
Tomas: That said, I'd like to take the opportunity to vent something that has been nagging me for a while An excellent description of your frustration, Tomas. I think it is important for the users of a system to explain to its creators what is bothering them. I want to make a couple of comments, but I want to stress first that I understand and even agree with many of your comments, and I don't want to imply that you shouldn't have made them... All the continuous NAnt restructuring... I'm going to be brutally honest here: Even though no 1.0 release of nant has ever been done, it has been used by people to build *real* systems for a really long time now. As you say, NAnt is not yet at 1.0, isn't it an unrealistic expectation of us early adopters to use a pre-1.0 release and constrain its developers not to change the system radically as they learn new things in order to get the product to 1.0? My big point is that many of the changes were done with little or no regard to the impact they might have on code outside the actual nant code base, and that's a problem now. One I personally consider a serious one. Again pre-1.0, an extension mechanism and general architecture that works well, is clear and is maintainable outweighs backward compatibility IMO. As an early adopter (who has written custom tasks as well) I fully expect this. Further, I also know that I don't *have* to upgrade. If I have that software working on a real project, I can use that version, migrating my tasks (if they are generic enough for reuse) at a later date, when the architecture stabilizes (which I would expect in the 1.0 version of NAnt). If you want people to use nant effectively, and be able to take advantage of what new builds of Nant offers easily, you need to start taking into consideration just how easy is going to migrate to a new build, and that takes far more than simply ensuring the .build files are valid. Again, after the 1.0 release, I would agree with this. But prior to that, ease of use, and adoption are IMHO more important goals. NAnt has the potential to be *the* definitive build tool for the .NET platform, but it won't be if it isn't as easy to use, understand, and install as possible. Constraining these with backward compatibility issues before the 1.0 release will make this a lot less likely to happen. NAnt has a much bigger hill to climb than Ant ever did to become a standard in the MS world. We at ThoughtWorks are engaged with clients who are looking for build solutions for .NET, and we are pushing NAnt as the answer to their needs. Right now the biggest barrier to adoption are things like the NAntContrib problem, the ease of use of VS -- not backward compatibility. Some of them want to see a 1.0 version before they will adopt. All of them want a simple turnkey installation, and a clear architecture. Finding the best solution to NAnt's architectural and deployment needs IMO outweighs backward compatibility at this time if NAnt is going to have wide appeal in the VS-dominated world of the MS shops out there. I would rather see radical changes in the code base as the NAnt developers improve the design, than see them stop short of optimal in the name of backward compatibility for what test versions of the code base (which is clear by the lack of 1.0 designation, and the attitude of the project members). Best, Bill William E. Caputo ThoughtWorks, Inc. Its the foolish cat that looks at the finger when it is pointing at the food --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] RE: NAntContrib update
Hi William, As you say, NAnt is not yet at 1.0, isn't it an unrealistic expectation of us early adopters to use a pre-1.0 release and constrain its developers not to change the system radically as they learn new things in order to get the product to 1.0? I know about this. However, I'd argue against the use of the term early adopter, and even more about the maturity of nant. Let's face it, nant has been usable for a long time. Heck, we've been using it successfully to build our project on a daily basis for more than *a year*. Early adopter? Then, perhaps, but you can hardly talk about preiews and early adopters on a system that has been on public use for year and a half at the least. And allow me to go even further: Look at all the big changes that have been made to nant over the past few months. It has become a much more complex piece of software, and it certainly has a large ammount of new functionality. And yet, with all those big changes, nat has only been declared up toa tentative 0.8.3 release. Heck, we've been strayining on the 0.8.X branch for what? More than six months, certainly. At that pace, how long will it take for a 1.0 release to come out? At least one year more at that speed. If the intention is to keep the nant core so unstable until that time, please, by all means let everyone now so that however wants can just fork over and forget about the actual nant project until that time, because the breaking changes have become so common that it's just not worth it anymore to keep up with it. Now, realize I'm not arguing against changing nant, or improving it. I'm arguing against doing it with no regards to ensuring people can keep up with it. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: [NAntC-Dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
Ian - you're a star - thanks! (and thanks for letting us know before I was going and do the same thing for some of the tasks. :) ) re: directory tree / namespaces. My own take is that tasks that have binary dependencies outside of NAnt at least at compile time (e.g. StarTeam with its interop requirement) should go into an optional directory, but that there's no harm in other tasks being merged into the main NAnt tree (e.g. I would make GacTask 'Nant.DotNet.Tasks.GacTask' in nant/src/NAnt.DotNet/Tasks and StarTeamTask 'Nant.Optional.SourceControl.Tasks.StarTeamTask in (maybe) nant/src/NAnt.Optional/SourceControl/Tasks). If the task help index page starts getting cluttered, we can always make it categorized based on namespace, and then alphabetical. In terms of how this is packaged into binaries, I think the main NAnt release could be everything apart from NAnt.Optional. The optional tasks could be a separate download and if required dropped into Nant/bin as normal (yes, its cluttered but will only be there if people need it, and it removes the need for sub-directories and multiple paths) ... but both of these things are minor - the fact that a lot of these tasks are going into NAnt at all is the main thing so thanks again! Mike Ian MacLean wrote: OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Ian I am concerned about the friction NAnt users are experiencing trying to contribute and in general use the NAntContrib tasks: http://www.iunknown.com/000278.html I would love to help clean up NAntContrib. I have some recent experience from updating the StarTeam tasks. I will take a look at the items Mike listed and see what I can do. If anyone can relay motes of wisdom please jump in. Kevin Miller --- From: Mike Roberts [EMAIL PROTECTED] Updating Nant-Contrib to latest Nant 2003-06-25 14:56 I spent a couple of hours looking at updating Nant-Contrb last night to compile against the latest NAnt, and realised its a lot more than just changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. Other updates since Nant 0.8.2 that effect Nant-Contrib include: - Logging has completely changed - Log Listeners have disappeared, so FileLogListener and the RecordTask need to change significantly - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') - Some stuff has moved to Nant.Core.Types - OptionCollection stuff seems to have completely changed - and more (I think) In light of this, the fact that I don't know Nant-Contrib very well, and also that there aren't a significant amount of tests, I'm now reluctant to update the whole of Nant-Contrib. I'm only using the mkiisdir task, so can just update that locally.. However, I'm going to bold now and give my opinion which the project leads are more than free to completely disregard. :) I don't really understand why Nant-Contrib and Nant are 2 separate projects. I can see the value in having separation to some extent (e.g. downloadable binaries, so that users don't have to download a bunch of tasks that they don't want), but on the other hand complete separation leads to (a) confusion in the user community and (b) the kind of situation that currently exists where there are significant differences between the 2 trees. I personally think it would be valuable, therefore, if the following happened: 1 - As a goal, the Nant-Contrib project should be phased out 2 - All the work (that is going to continue to live on) from Nant-Contrib should be (task-by-task) brought into the Nant project, maybe under a separate directory called 'optional-tasks'[a] 3 - The Nant buildfile should compile both the NAnt Core, the existing extra tasks and the 'optional-tasks' so that the latter of these don't get out of sync with changes to the
Re: [NAntC-Dev] RE: [nant-dev] NAntContrib update was ( UpdatingNant-Contrib to latest Nant)
Tomas Restrepo wrote: Ian, Why optional? If we're gonna move them, you might as well move them right. For example, some Nant tasks should go into the main Nant builds... Things like GAC and XSD are fairly common DotNet development operations (I don't know what criteria you guys are using for separating the tasks, though, so I may be mistaken here). totally. I have been meaning to move about 6 tasks into Nnt.DotNet ( gac, xsd etc ) and some others into NAnt.Win32 ( comRegister etc ) First priority was to get everything compiling. We can move tasks to their appopriate namespaces as needed. However I would still consider tasks like starteam optional - apologiesto those starteam users who consider them crucial. re rant I hear you and hopefully this will be the last of the re-structuring for a good while. I think the code base is cleaner for it and it will help us going forward. I apologise for the inconvenience to task writers. However it took only around 3 hours to get all of NAntContrib ( 48 tasks ) compiling. Granted I have more familiarity with the nant sources and what has changed than most task writers so I'd be happy to put together a checklist for moving tasks to compile to the latest nant. You are right - many of these changes were done without much consideration for external task writers. To be honest I wasn't aware that so many people were writing external tasks. re version number - like many open source projects we've just kinda been bumping it every time there is a release. Personally I think that with the recent addition of fileset references, cvs tasks and multiple framework support NAnt is getting close to feature complete. After the upcoming release I propose that we gather a list of required features for 1.0 and start setting up a timeframe. You are right - nant has been out there for quite some time now and is used by more and more people. Its getting stable enough that we can stop making re-structuring changes that will break existing tasks - unless there is really good reasons for adding them. so thanks Tomas - points taken on board. Ian rant That said, I'd like to take the opportunity to vent something that has been nagging me for a while: All the continous Nant restructuring. Granted, some good things have gone on, and the base is much clear. However, I'm going to be brutally honest here: Even though no 1.0 release of nant has ever been done, it has been used by people to build *real* systems for a really long time now. And you know what? Everyone I've met using Nant has created their own tasks to make their builds more powerful/simple/easier, and that's a *good* thing. However, all the restructuring going on keeps breaking their tasks code, and that ain't nice. Hell, we can't even keep NAntContrib compiling and that's supposed to be *the* nant partner-project. How do you expect people to keep up with all the changes you guys do? (and I'll be even more brutal here and say many of those changes have been fairly gratuitous, with very, very little added value). My big point is that many of the changes were done with little or no regard to the impact they might have on code outside the actual nant code base, and that's a problem now. One I personally consider a serious one. The sad part is, many of them could've been done in a gradual maner, deprecating and wrapping things so that people could slowly migrate things over. Things like the logging infrastructure, Option sets, etc, could've been approach in such a way that they didn't force people into having to change perfectly working code all at once, for example. If you want people to use nant effectively, and be able to take advantage of what new builds of Nant offers easily, you need to start taking into consideration just how easy is going to migrate to a new build, and that takes far more than simply ensuring the .build files are valid. Just something to think about. /rant --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAntContrib update was ( Updating Nant-Contrib tolatest Nant)
Gert Driesen wrote: How do you propose to deal with the NAntContrib sources ? will they be moved into /src/NAnt.Optional and /tests/NAnt.Optional or will they be integrated into the current namespace structure ? src/NAnt.Optional to start with and move those tasks that fit into NAnt.DotNet or NAnt.win2 or whatever. I think Optional has a place for the less frequently used tasks. I would still like to get rid of needing a COM interop assembly for SourceSafe (and if possible also for StarTeam, don't know if that's possible though). Can't we create a wrapper for the vss commandline tool ? why ? how else do you propose to connect to com code ? Sorry, but forgoing a perfectly good COM based api to wrap a command line tool seems completely backward to me. I don't understand the problem you have with interop assemblies - they are simply metadata and mappings that allow you to call COM objects. Is there somthing inherently evil about them that I don't know about ? Feel free to write wrappers in managed c++ if you want. Ian Gert On Sat, 2003-06-28 at 18:53, Ian MacLean wrote: OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. Ian I am concerned about the friction NAnt users are experiencing trying to contribute and in general use the NAntContrib tasks: http://www.iunknown.com/000278.html I would love to help clean up NAntContrib. I have some recent experience from updating the StarTeam tasks. I will take a look at the items Mike listed and see what I can do. If anyone can relay motes of wisdom please jump in. Kevin Miller --- From: Mike Roberts [EMAIL PROTECTED] Updating Nant-Contrib to latest Nant 2003-06-25 14:56 I spent a couple of hours looking at updating Nant-Contrb last night to compile against the latest NAnt, and realised its a lot more than just changing the namespace hierarchy from Sourceforge.Nant to Nant.Core. Other updates since Nant 0.8.2 that effect Nant-Contrib include: - Logging has completely changed - Log Listeners have disappeared, so FileLogListener and the RecordTask need to change significantly - Some classnames have changed (e.g. 'MsftFXSDKExternalProgramBase') - Some stuff has moved to Nant.Core.Types - OptionCollection stuff seems to have completely changed - and more (I think) In light of this, the fact that I don't know Nant-Contrib very well, and also that there aren't a significant amount of tests, I'm now reluctant to update the whole of Nant-Contrib. I'm only using the mkiisdir task, so can just update that locally.. However, I'm going to bold now and give my opinion which the project leads are more than free to completely disregard. :) I don't really understand why Nant-Contrib and Nant are 2 separate projects. I can see the value in having separation to some extent (e.g. downloadable binaries, so that users don't have to download a bunch of tasks that they don't want), but on the other hand complete separation leads to (a) confusion in the user community and (b) the kind of situation that currently exists where there are significant differences between the 2 trees. I personally think it would be valuable, therefore, if the following happened: 1 - As a goal, the Nant-Contrib project should be phased out 2 - All the work (that is going to continue to live on) from Nant-Contrib should be (task-by-task) brought into the Nant project, maybe under a separate directory called 'optional-tasks'[a] 3 - The Nant buildfile should compile both the NAnt Core, the existing extra tasks and the 'optional-tasks' so that the latter of these don't get out of sync with changes to the core. 4 - ... a result of which would be the tasks imported from Nant-Contrib would also be updated to fit in with latest NAnt [a] - I actually
