Swoogan wrote:
John Cole wrote:
There was a discussion on this topic a few months ago. The main point of
contention was installing NAnt/NAntContrib to the same directory or not and
whether or not to include NAntContrib at all in the installer.
I was warring with the same dilema as far as NAnt/NAntContrib. My plan was to install to the same directory as NAnt because, AFAIK, the assemblies have to go into the NAnt bin dir (or a relative path off of it) for NAnt to load them. I was going to make the doc directory install as nantcontrib-doc and nant install into nant-doc or just doc.
For the record, there are currently three basic alternatives for installing NAntContrib...
1) Install NAntContrib to the same folder as NAnt.
PRO: NAntContrib is automatically detected in all NAnt builds with no further work
CON: The combination is fragile. NAntContrib needs to be completely reinstalled if NAnt is reinstalled (?)
CON: Difficult to remove NAntContrib if you no longer want it (for some reason), even for a single build script
2) Install NAntContrib to a different folder, tinker with NAnt.exe.config to load the NAntContrib dlls
PRO: NAnt/Contrib installation decoupled
CON: Have to tinker with NAnt.exe.config
CON: Still difficult to remove NAntContrib for instances you don't want to use it
3) Install NAntContrib to a different folder, add a <loadtasks> line in every build script that uses NAnt tasks.
PRO: NAnt/Contrib installation decoupled
CON: Extra overhead in each build script. Currently, also creates non-portable scripts unless this method becomes standardised.
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.
NAnt could scan the bin/ext folder for descriptors on startup in a similar fashion to the NAnt.exe.config method, but this allows for specific support such as disabling all extension libraries, or disabling a named library when invoking NAnt.
PRO: Libraries decoupled from NAnt installation
PRO: Libraries "automatically" discovered on NAnt startup
PRO: Libraries can be easily registered/deregistered by adding or removing their own locator... there's no possibility of corrupting your NAnt install by breaking the xml structure - just one library.
CON: It's not implemented yet
The other thing I like about this approach is that is allows extension to namespaces in the future... the namespace can be specified in the xml locator (by default uses the default namespace), or the namespace for a named library can be overridden from the commandline when invoking NAnt (In case of a namespace clash with a particular build script).
Also, it would be reasonably simple to create a <registerlibrary> (and <deregisterlibrary>?) NAntContrib task to create this locator dynamically.
Thoughts?
Regarding installing/downloading NAntContrib in the NAnt installer, does the Inno download feature support a local-cached copy of the downloaded module, say if you were installing NAnt on many developer machines you don't want to have to download NAntContrib each time... if so, this sounds like an excellent compromise!
Phew, longwinded. 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
