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/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
