Perhaps we should explore a new mechanism for extension libraries in NAnt, with inspiration taken from the Java jre/lib/ext idea...
4) Install NAntContrib to a different folder, and add an xml descriptor/locator in NAnt/bin/ext which describes the library.
why not extend NAnt.exe.config rather than adding another config file. One of the things I like about the Nant model is that you don't *need* to have a task registration scheme the way Ant does because of the attribute based auto-scan mechanism.
I'm looking at a principle of minimisation of damage. No matter how badly you (or some automated task) break the xml structure for the library you are trying to install (or modify or uninstall), you can't stop anything but your library from working.
Conversely, if NAnt.exe.config doesn't parse, NAnt doesn't work.
I'm not talking about describing the tasks in the locator, just a simple xml file in the order of:
<library name="NAntContrib">
<description>
Optional tasks for NAnt
</description>
<assemblies>
<assembly location="C:/path/to/NAntContrib.dll" />
</assemblies>
</library>Also, it would be reasonably simple to create a <registerlibrary> (and <deregisterlibrary>?) NAntContrib task to create this locator dynamically.except that you couldn't register NAntContrib itself if you didn't already have it registered in order to be able to use those tasks :)
The NAntContrib build script could use <loadtasks> to load its own tasks before registering itself. As a bonus, it provides a poor man's self-test mechanism... if the tasks don't load, it can't register itself ;-)
I just think such a "register" task belongs more in NAntContrib than NAnt core.
I still think that it would be better to extend the existing config file extra functionality is required. It already allows you to specify paths to scan for assemblies and I think to exclude specific assemblies.
But not to give assemblies or groups of assemblies names, so you could then exclude those assemblies when running a particular build script through commandline options.
It may be the case that this last isn't a good idea, I still think that multiple xml fragments is less fragile and more manageable than one mammoth xml file... not only for the damage minimisation, but because you can easily tell (at a glance) what libraries are set up in a particular installation by scanning a directory, but scanning through an xml file to see which assemblies are referenced is more time consuming.
Regards,
-- Troy
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
