- IIS Tasks (including <mkiisdir>) - Should this go in NAnt.Win32 ?
- <gac> Should this go in NAnt.DotNet ?
I'll email the new files to nant-developer when I am done.
Cheers,
Mike
Ian MacLean wrote:
Mike,
I agree with you on most of these. The original idea was to have all sorts of specialized tasks go in nantcontrib and it would have a lower barrier to entry so that Joes random task that only 10 users need to use could be available if needed. without having to add it to the main project. Since the last refactoring nant has a folder structure more amenable to slotting in extra task assemblies so moving stuff from NAntContrib should be easier.
A lot of the reason for the recent slippage is that Scott the project Admin had been doing much of the work of managing NAntContrib. He has been on vacation for the last 3 or 4 weeks and I've been more focused on the NAnt refactoring stuff recently so NAnContrib has kinda been left by the wayside.
4[a] there are a whole bunch of nancontrib tasks - the .net related ones like gac, regasm etc that I have meen meaning to move across for a while. There is some base class refactoring that I need to do thats been putting me off. Is the <mkiisdir> task commonly used by you and your clients ? If so we could move it across to NAnt so that it can get used more easily.
I'm still going be busy with the 0.83 nant release thats coming up. After that I'll have some time to pull some tasks across and get NAntContrib building cleanly against nant cvs.
Ian
....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 _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
------------------------------------------------------- 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 _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
