My humble 2c worth ... Option 4 looks like an elegant (but long term) solution. How about a another radical proposal:
The NAntContrib installer also installs a suitable version of NAnt PROS: One install installs both. Environment vars, paths all fixed up correctly. Suitable versions of NAnt/Contrib released as a package. CONS: Tightly coupled (joined at the hip more like). If NAntContrib lags (in releases), you don't get the latest version of NAnt (easily anyway). ... could be a completely wacky idea though ... Regards Subbu -----Original Message----- From: Troy Laurin [mailto:[EMAIL PROTECTED] Sent: Wednesday, 16 February 2005 10:58 AM To: nant-developers@lists.sourceforge.net Subject: Re: [nant-dev] Windows installer for binary distribution. 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 ------------------------------------------------------- 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
